implement: Phase 25.5 device config from JSON file

- Create config/device.json with owner_name, car_model, device_name, avatar_path
- Update app_account.py to load owner_name and avatar_path from config
- Update app_car.py to load car_model and device_name from config
- Update base.html template to use avatar_path from config instead of hardcoded
- Add graceful fallback to hardcoded defaults if config file missing
- Document in deploy/readme.md and readme.md how to customize device identity
- Update PLAN.md Phase 25.5 to reflect current implementation and future server sync

Benefits:
- No code edits needed to customize Pi (edit JSON file only)
- Offline-first: all values loaded from local file at startup
- Connection-driven sync planned for Phase 25.5a (sync when internet available, not on timer)
- Server becomes source of truth after Phase 25.5a implementation

All 63 tests passing. Database filename still based on owner_name, with migration warning in docs.

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

PLAN.md

@@ -1482,44 +1482,44 @@ must be fixed, redeployed uncommitted, and the affected in-car test repeated bef
 and **ready-to-install** sign-off. Afterward, the owner handles permanent installation outside the
 phase roadmap.
 
-### Phase 25.5: Device profile & configuration sync — 🚧 PLANNED (local config mgmt)
-**Unstarted.** Replace hardcoded `account.name`, `car.model`, and avatar with managed configuration editable on the server and synced to the Pi. Enables multi-device/multi-user scenarios and eliminates manual code edits.
+### Phase 25.5: Device profile & configuration sync — 🚧 IN PROGRESS (config file + server sync planning)
+**Config file implemented; server sync planned.** Replace hardcoded values with `config/device.json`, editable by users without code changes. Server sync is eventual-consistency, connection-driven (not time-driven) to handle offline-first car scenarios.
 
-#### Scope
+#### Current state (implemented)
+- **`config/device.json`** (new): stores device identity fields:
+  - `owner_name`: "quoije" (displayed in topbar, replaces `account.name` hardcode)
+  - `car_model`: "Yaris 2013" (displayed in sidebar, replaces `car.model` hardcode)
+  - `device_name`: "Yaris OBD" (displayed on portal, not yet used on Pi)
+  - `avatar_path`: "img/yaris.png" (sourced by template, replaces hardcoded path)
+- **Code changes**:
+  - `modules/app_account.py`: loads `owner_name`, `avatar_path` from JSON on startup with fallback to hardcoded defaults
+  - `modules/app_car.py`: loads `car_model`, `device_name` from JSON on startup with fallback to hardcoded defaults
+  - `templates/base.html`: avatar image now sources from `account.avatar_path` (loaded from config) instead of hardcoded path
+- **Offline-first design**: All values loaded from local JSON at startup; no network required to boot with customized identity. Server sync is *eventual*, not critical.
+
+#### Future scope (Phase 25.5a+)
 - **Server-side config editor**: add a simple "Device Settings" page on the remote portal (login-protected, device-scoped) with editable fields:
-  - Device nickname (device_name, for display on the portal and Pi topbar)
-  - Car model/year (already in DB via Phase 24's `device_id` + `car_model`, but allow user override)
-  - Profile picture upload (stored server-side, served to both portal and Pi via API endpoint)
-  - Owner name / username (replaces hardcoded `account.name`)
-- **Pi-side config sync**: 
-  - Add a new `device_config` table to local SQLite (device_name, owner_name, car_model, avatar_url, sync_timestamp, hash)
-  - On Pi startup and every 30 minutes, fetch the latest config from the remote server via a new `/api/device-config` endpoint (authenticated with device_key, not user login)
-  - If hash differs, update local config table and restart the web app (or hot-reload via settings API)
-  - Fall back gracefully to hardcoded defaults if server is unreachable
-- **UI updates**:
-  - Pi topbar shows the synced `device_name` instead of hardcoded car model (or car model from synced config)
-  - Pi sidebar shows the synced owner_name instead of hardcoded `account.name`
-  - Avatar image sourced from synced `avatar_url` (served from server, fallback to local placeholder)
-  - All trip/tracking records use synced values at capture time (no retroactive changes to history)
-- **Device authentication**: use an existing `device_key` (generated on first Pi provisioning, stored in `/home/yaris/app/yaris-obd/.device-key` or env var) to authenticate the `/api/device-config` request. Server validates device_key against the Postgres `devices` table.
-
-#### Implementation phases
-1. **Server (Phase 25.5a)**: add `device_name`, `owner_name`, `avatar_blob` columns to Postgres `devices` table; create `/api/device-config` read endpoint and `/api/device-config` POST endpoint for edits; add Settings UI to portal for these fields.
-2. **Pi config table & sync (Phase 25.5b)**: add `device_config` SQLite table; implement 30-min sync fetch on Pi; hot-update app globals if config changes.
-3. **UI updates (Phase 25.5c)**: update topbar, sidebar, avatar rendering to use synced config; test full cycle (edit on server → Pi syncs → UI reflects change).
-4. **Acceptance (Phase 25.5d)**: multi-sync cycle test, network loss recovery, avatar upload/display, retroactive trip behavior.
+  - Device nickname (device_name)
+  - Car model/year (car_model)
+  - Profile picture upload (avatar stored on server)
+  - Owner name / username (owner_name)
+- **Pi-side sync** (connectivity-driven, not time-driven):
+  - Pi syncs config from server **only when internet is available** (when cellular/WiFi connects), not on a fixed 30-min timer
+  - Server-side changes → Pi receives on next connectivity event → updates `config/device.json` → restarts web app or hot-reloads globals
+  - If server unreachable, Pi continues with last-synced config from local JSON (already loaded at startup)
+- **Device authentication**: use an existing `device_key` to authenticate `/api/device-config` requests, validated server-side against Postgres `devices` table.
 
 #### Benefits
-- No code edit needed to rebrand a deployed Pi
-- Server becomes the source of truth for device identity (enables future multi-Pi/multi-car scenarios)
-- Avatar management centralized
-- Graceful fallback if server unavailable (Pi uses last-synced config)
-- Enables future features: device rename, device status on portal, bulk config across devices
+- ✅ No code edit needed to customize deployed Pi (today: edit JSON file manually)
+- ✅ Offline-first: Pi boots with identity immediately, no network dependency
+- ✅ Connection-driven sync: sync happens when internet available, not wasting resources on offline car
+- 🚧 Server becomes source of truth (after Phase 25.5a)
+- 🚧 Enables multi-Pi/multi-car scenarios (after Phase 25.5a)
 
 #### Trade-offs
-- Adds config sync complexity and latency (eventual consistency)
-- Requires device authentication key rotation strategy (future)
-- Metadata storage (avatar blob) requires server-side image handling
+- Sync is eventual-consistency (changes on server may take hours to reach offline car)
+- Manual JSON edit required today (before Phase 25.5a server UI is built)
+- Avatar must be placed in `static/img/` directory (no upload yet)
 
 ---