Refresh docs and reorder roadmap

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

server/README.md

@@ -21,6 +21,13 @@ docker-compose stack on an unraid server (or any Docker host).
   staged on disk and reassembled + sha256-verified once all have arrived, then
   recorded the same way as the single-shot endpoint. This is what the Pi
   actually uses for real dashcam files — see "Why chunked uploads" below.
+- `GET /api/device-config` — device-authenticated config fetch used by the Pi's
+  identity-sync thread and local **Sync now** action.
+- `POST /api/v1/device-config/ack` — device-authenticated config-sync
+  acknowledgement so the server can record the last applied version/time.
+- `/settings/device` + `/api/v1/portal/devices*` — login-protected multi-device
+  management UI/APIs for create, delete, rotate key, edit config, and request
+  sync.
 
 Both `/api/v1/tracking/batch` and the dashcam upload endpoints require two
 headers: `X-Device-Name` and `X-Api-Key` (see
@@ -28,13 +35,11 @@ headers: `X-Device-Name` and `X-Api-Key` (see
 Postgres is **not** published to the LAN — only the `api` container talks to
 it, over the internal compose network.
 
-**CORS is enabled on every response** (`Access-Control-Allow-Origin: *`) so a
-device's registered API key can be used directly from browser JS running on a
-*different* origin — specifically, the Pi's phone-relay feature (see
-[PLAN.md](../PLAN.md) Phase 11), where a phone's browser calls this API
-straight from a page served by the Pi itself. This is safe here because
-auth is header-based (`X-Device-Name`/`X-Api-Key`), not cookie/session-based,
-so a permissive origin can't be used to steal a logged-in session.
+**CORS is enabled on every response** (`Access-Control-Allow-Origin: *`) for the
+device-authenticated API surface. This keeps header-authenticated device calls
+usable from browser-based tooling and same-user cross-origin utilities without
+introducing cookie/session theft risk, because device auth is explicit
+(`X-Device-Name`/`X-Api-Key`) rather than ambient session auth.
 
 ## Deploying on unraid
 
@@ -65,12 +70,11 @@ so a permissive origin can't be used to steal a logged-in session.
    docker compose ps
    curl http://localhost:8098/health
    ```
-5. Sign in to the remote portal and open `/settings/device` to edit the synced
-   owner/car/device/avatar values for the configured `DEVICE_NAME`. If the Pi
-   has local **Sync with server** enabled, those values hot-reload into the
-   running Pi UI after the next successful sync. Phase 25.5c also adds a
-   multi-device list, one-time API-key reveal, key rotation, and a request-sync
-   action on that page.
+5. Sign in to the remote portal and open `/settings/device` to manage devices:
+   create/delete devices, reveal a one-time API key, rotate keys, edit synced
+   owner/car/device/avatar values, and request a sync. If the Pi has local
+   **Sync with server** enabled, those values hot-reload into the running Pi UI
+   after the next successful sync.
 
 ### Upgrading an existing unraid deployment
 
@@ -87,10 +91,12 @@ docker compose up -d --build
 
 Phase 25.5a adds the device identity sync columns (`owner_name`, `car_model`,
 `device_name`, `avatar_path`, `config_version`, `config_updated_at`) used by the
-Pi/server config sync flow. The browser portal page at `/settings/device` edits
-those values; the Pi applies them on its next successful sync when local
-**Sync with server** is enabled, and Phase 25.5b now hot-reloads the in-process
-UI fields instead of requiring an app restart.
+Pi/server config sync flow. Phase 25.5c adds multi-device provisioning/status
+columns (`last_config_sync_at`, `last_config_sync_version`,
+`force_sync_requested_at`, `api_key_rotated_at`). The browser portal page at
+`/settings/device` edits those values; the Pi applies them on its next
+successful sync when local **Sync with server** is enabled, and Phase 25.5b
+hot-reloads the in-process UI fields instead of requiring an app restart.
 
 ## Registering a device and getting an API key
 
@@ -104,14 +110,23 @@ This prints a one-time API key — copy the `YARIS_DEVICE_NAME` /
 `YARIS_API_KEY` values into the Pi's upload-client config. Only the
 key's sha256 hash is stored server-side; the raw key is never shown again.
 
+On the Pi, those credentials can now be entered through the local Settings page
+instead of editing `db/upload_creds.env` over SSH. The same page also exposes
+**Test connection** and **Sync now** actions.
+
 The browser portal at `/settings/device` can now do the same workflow without
 shell access:
 
 - create a new device
+- delete a non-default device
 - reveal a one-time API key
 - rotate the API key later
 - request a sync for the selected device
 
+Current limitation: device management is multi-device, but the main remote
+overview/history/dashcam browsing pages still scope themselves to one
+configured `DEVICE_NAME` until a portal-wide device selector/filter is added.
+
 ## Exposing it outside the LAN
 
 Two options, either works with this API unchanged:
@@ -149,7 +164,7 @@ byte-for-byte sha256-verified against the source on the Pi.
 
 The Pi's web UI has a setting to pause dashcam file uploads while keeping
 GPS/trip log uploads running — no server-side change needed, the Pi simply
-stops calling `/api/v1/dashcam/upload` while the toggle is off.
+stops calling the dashcam upload status/chunk endpoints while the toggle is off.
 
 ## Local development / testing without unraid