docs: record verified Pi and unraid deployment state

- note verified Pi IP after WiFi card change
- record successful 2026-08-10 Pi/unraid rollout
- document unraid checkout divergence and temp-clone deploy workaround

Co-authored-by: Copilot <[email protected]>

PLAN.md

@@ -1528,8 +1528,9 @@ phase roadmap.
 - Sync disabled if `YARIS_SERVER_URL` or `YARIS_DEVICE_KEY` not set
 - **2026-08-10 access verification**: SSH access confirmed to Pi at `[email protected]`
   (new WiFi card/subnet) and to unraid via `ssh unraid` (`[email protected]`).
-  At verification time, Pi checkout was still on `d7b9bb6` and unraid server checkout on
-  `24a2323`, so both still need a deploy/pull to pick up the latest Phase 25.5a code.
+  Follow-up deployment succeeded the same day: Pi fast-forwarded from `d7b9bb6` to `cd004fb`,
+  service restarted cleanly, and unraid rebuilt the API stack after manually applying
+  `migrate_phase25_5a.sql`.
 
 #### Next phase (Phase 25.5b)
 - Hot-reload handler to apply config changes without restart
@@ -1577,6 +1578,10 @@ phase. Scope, at a high level (not yet designed in detail):
   Container names: `yaris-obd-db` (Postgres 17), `yaris-obd-api`. For existing databases, also run
   the mounted migration scripts manually, e.g.
   `docker compose exec db psql -U yarisobd -d yarisobd -f /docker-entrypoint-initdb.d/migrate_phase25_5a.sql`.
+  **Important 2026-08-10**: this checkout had a long-diverged local `shameless-aislop`
+  (`ahead 136, behind 146`), so `git pull --ff-only` failed. To avoid destroying local history, the
+  Phase 25.5a deploy was performed from a fresh temporary clone while reusing the same `.env` and
+  Docker data. Reconcile or replace the old checkout before relying on it for future ff-only deploys.
 - **Pi deploy loop**: `ssh yaris@<pi-ip>` (alias `yarisobd`) ->
   `cd ~/app/yaris-obd && git pull --ff-only` -> `sudo systemctl restart yaris-obd.service`
   (passwordless sudo confirmed via `yaris ALL=(ALL) NOPASSWD: ALL`). App stdout/stderr goes to