feat: implement Wi-Fi provisioning and persistent configuration

PLANS.md

@@ -193,7 +193,7 @@ builds reproducibly with the locked platform and partition configuration.
 
 ## Milestone 003 — Wi-Fi provisioning and persistent configuration
 
-**Status:** `NOT_STARTED`
+**Status:** `COMPLETE`
 
 ### Objective
 
@@ -225,9 +225,57 @@ access-point provisioning flow.
 
 ### Evidence
 
-Completion evidence is not yet available because this milestone has not
-started. Required evidence includes NVS tests and target-board logs for first
-boot, successful station connection, reboot persistence, and fallback recovery.
+- On 2026-09-03, `./scripts/run_host_tests.sh` reported
+  `health state tests: PASS`, `wifi configuration tests: PASS`,
+  `configuration NVS tests: PASS`, `provisioning protocol tests: PASS`, and
+  `web asset reproducibility: PASS
+  (b36a6203a78964a324e3d56986a99abb7e36a48a84688cb4ecfe4ac1934b9f92)`.
+  The tests exercise credential length and control-byte bounds, invalid-input
+  non-mutation, mandatory reconfiguration guards, real store code across an
+  NVS reinitialization, schema mismatch, reset, strict two-field JSON parsing,
+  and malformed or duplicated request fields.
+- After a clean on 2026-09-03,
+  `/home/sasa/.platformio/penv/bin/pio run -e esp32-c6-devkitm-1` completed
+  with `[SUCCESS]` in 46.25 seconds. PlatformIO reported 37,452 bytes of RAM
+  and 985,280 of 2,097,152 application bytes in use; the independent size hook
+  reported `firmware.bin uses 985920/2097152 bytes in partition factory`.
+- `/home/sasa/.platformio/penv/bin/pio run -e esp32-c6-devkitm-1 --target
+  buildfs` completed with `[SUCCESS]` and reported
+  `littlefs.bin uses 2031616/2031616 bytes in partition littlefs`. The image
+  contains deterministic compressed application and provisioning pages; its
+  SHA-256 was
+  `f3e529542737221d46146f46ff57eb3a88a1b3c5b25c9f4298b9d3e3e22a7d3a`.
+- The application and filesystem images were written to the physical
+  ESP32-C6FH4 and hash-verified. A production first boot with empty
+  configuration reported `App version: 0.3.0`,
+  `No usable saved station configuration; enabling fallback`,
+  `Fallback access point ready: SSID=maze32-F7B9,
+  URL=http://192.168.4.1/provision`, DHCP at `192.168.4.1`,
+  `Provisioning endpoints ready`, and `Health state: serving`.
+- The isolated `milestone-003-device-test` environment exercised the real NVS
+  and network manager without accessing local Wi-Fi secrets. One continuous
+  target log reported `credentials saved; restarting`, reset reason `SW_CPU`,
+  `credentials survived restart`, station connection to the persisted test
+  SSID with three bounded retries, `Station connection timed out or exhausted
+  retries; enabling fallback`, and `failed station returned to fallback;
+  credentials cleared`. Normal production firmware was restored afterward and
+  its boot log confirmed the test credentials were absent.
+- On 2026-09-03, the project owner used the device-hosted provisioning page
+  from a separate client to save credentials for `Mazda7`; no credential was
+  exposed in the test record. A subsequent physical-board reboot loaded that
+  persisted SSID, associated using WPA2, received `192.168.1.50`, reported
+  `Network state: station_connected` and `Station connected:
+  IP=192.168.1.50`, registered the HTTP and provisioning routes, and reached
+  `Health state: serving`.
+- Live requests over `Mazda7` returned
+  `{"state":"station_connected",...,"ip":"192.168.1.50"}` from
+  `/api/wifi/status`, a healthy version `0.3.0` response from `/health`, and
+  the decompressed Russian provisioning page from `/provision`. A deliberately
+  invalid two-field configuration request returned HTTP 400. A final board
+  reboot again loaded and connected to `Mazda7`, proving the rejected request
+  did not alter the persisted valid configuration.
+- All five acceptance criteria therefore have recorded evidence. Milestone 004
+  remains `NOT_STARTED`.
 
 ## Milestone 004 — HTTP, WebSocket, sessions, and lobby