Firmware: WiFi fast-connect cache (skip scan + DHCP on the next wake)

After a successful home-WiFi connection, caches BSSID/channel and
IP/netmask/gateway/DNS in NVS. The next wake's first connect attempt
uses the cached BSSID/channel (skips the all-channel scan) and applies
the cached IP directly once the link comes up (skips DHCP) -- a couple
fewer seconds of radio-on time per wake, free every wake since nothing
about the network actually needs renegotiating most of the time.

Falls back to a normal scan+DHCP attempt, and clears the cache, if: the
fast attempt itself fails, or it "succeeds" at the WiFi layer but the
full fetch cycle then fails anyway (a stale cached IP/DNS/gateway that
associates but can't actually reach the server). Also cleared on
(re)provisioning and factory reset, since a new network shouldn't try
to reuse the old one's cache.

The static-IP path needed care to get right without touching untested
territory: esp_netif_set_ip_info() only posts IP_EVENT_STA_GOT_IP (what
the existing connect-wait logic blocks on) once the netif is already
up, which the internal netif-glue's own WIFI_EVENT_STA_CONNECTED
handler guarantees by running first (registered earlier, in
esp_netif_create_default_wifi_sta()) -- confirmed against ESP-IDF's own
static_ip example and esp_netif_handlers.c source rather than assumed.
Falling back after a failed fast attempt also needed an explicit
esp_netif_dhcpc_start() first: esp_netif_dhcpc_stop() leaves the netif's
DHCP status STOPPED rather than resetting to INIT, and left alone the
glue would silently re-post the stale cached IP on the next connect
instead of actually running DHCP (esp_netif_action_connected).

Version bumped to 1.1.0 (real feature, not just a fix); build-verified
clean on both board configs (devkit 8MB, XIAO 4MB), no new warnings.

firmware/README.md

@@ -84,6 +84,26 @@ reflashing. The Kconfig value only applies before the device has ever
 successfully reached a configured server, or if the response doesn't
 include a valid interval.
 
+### WiFi fast-connect
+
+After a successful home-WiFi connection, the device caches the AP's
+BSSID/channel and its own IP/netmask/gateway/DNS in NVS. The *next*
+wake's first connect attempt uses that cache to skip the all-channel
+scan (`wifi_config.sta.bssid_set` + a channel hint) and DHCP (a static
+IP set directly) -- typically a couple of seconds less radio-on time
+per wake, free every wake since it's already-known information, not a
+fresh negotiation.
+
+If that cached attempt fails outright, or it "succeeds" at the WiFi
+layer but the server turns out to be unreachable (a stale cached IP,
+DNS entry, or gateway), the cache is cleared and that wake falls back to
+a normal scan + DHCP -- and the *next* wake tries the fast path again
+from a fresh cache. A (re)provisioning event or factory reset also
+clears it, since a new network shouldn't try to reuse the old one's
+cached BSSID. No user-facing config for this -- it's purely an
+internal optimization, invisible unless you're watching the serial log
+(`"fast path: cached BSSID/channel + static IP"` vs `"attempt N/M"`).
+
 ## First boot
 
 With no stored WiFi config (a fresh device, or after erasing NVS -- see