Expand remote portal dashcam scope

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

PLAN.md

@@ -1093,30 +1093,38 @@ remaining cleanup once all the functional phases above have landed:
   framework rewrite would add deployment weight and offline assets on the Pi without improving
   the tracker features, and would discard the foundation deliberately built before Phases 16-21.
 
-### Phase 23: Remote trip portal with shared web UI — 🚧 PLANNED
+### Phase 23: Remote trip + dashcam portal with shared web UI — 🚧 PLANNED
 **Added 2026-08-09; intentionally scheduled after Phase 22.** Phase 22 first establishes the final
 visual language and complete in-car interface. Building the remote portal afterward avoids
 duplicating the current unfinished theme and lets both deployments deliberately share the same
-finished shell, components, trip list, route map, timeline replay, units, and responsive behavior.
+finished shell, components, trip list, route map, timeline replay, dashcam library, units, and
+responsive behavior.
 
 Extend the existing self-hosted `server/` deployment from an upload-only API into a secure remote
-web portal backed by its Postgres tracking data, so trip history and all recorded trip details can
+web portal backed by its Postgres tracking data and uploaded dashcam archive, so trip history,
-be viewed away from the car:
+recorded trip details, and footage can be accessed away from the car:
 - Add server-side trip boundary/index data equivalent to Phase 18, generated from uploaded tracking
   points without changing or deleting the raw records. Expose trip summaries, full/downsampled
   routes, timestamps, distance in km/mi, average/max speed in km/h and mph, and timeline replay.
 - Reuse the redesigned Phase 22 Jinja/Bootstrap UI rather than creating a visually separate app.
   Extract/share presentation assets where practical so local and remote pages do not drift, while
   keeping their data providers and available actions explicit.
+- Make the uploaded dashcam archive a required first-class remote page, matching the redesigned
+  in-car imported-video library: sortable/searchable file list, relative path, size, timestamp,
+  thumbnails, inline H.264 playback with Range/seeking support, and an explicit download action for
+  individual original files. Downloads must stream from server storage with safe
+  `Content-Disposition`, bounded/traversal-safe paths, and no whole-video memory buffering. Remote
+  deletion is not included unless it is designed later with separate safeguards; the server remains
+  the archive/backup.
 - Put an always-visible environment indicator in the shared shell: **In-car / Local Pi** on
   `yaris.local`, and **Remote server** on the hosted portal. Page title, navigation, and status
   styling must also make the context unambiguous so the user cannot mistake remote historical data
   for a live connection to the car.
-- The remote portal is primarily historical/read-only. Hardware-only actions (physical dashcam
+- The remote portal is historical/read-only. It should feel like the same product, but render only
-  mount/delete/import, live OBD/GPS state, Pi settings) must be hidden, disabled with a clear
+  server-relevant navigation and data—not redacted/empty imitations of unavailable hardware.
-  explanation, or replaced by their remote equivalent rather than appearing to control the car.
+  Physical dashcam mount/import/delete, live OBD/GPS, cellular status/configuration, Pi health, and
-  Uploaded dashcam archive browsing can be included if it reuses the existing server storage
+  local Pi settings are omitted entirely. Trip history/replay and the uploaded dashcam archive are
-  safely, but trip detail/replay is the required first scope.
+  the required remote scope.
 - Add real human-user authentication and secure sessions for the internet-facing UI. Existing
   device `X-Device-Name`/`X-Api-Key` upload authentication remains separate and must not become a
   browser login mechanism. Preserve Cloudflare Tunnel compatibility and do not expose secrets in
@@ -1124,7 +1132,8 @@ be viewed away from the car:
 - Support selecting a vehicle/device if more than one is registered later, while defaulting
   cleanly to the current Yaris. Keep trip APIs scoped to the authenticated user/device.
 - Deploy only after Phase 22 is complete: rebuild the unraid Docker stack, verify migrations against
-  copied data first, compare remote trip calculations with uploaded Pi records, and browser-test
+  copied data first, compare remote trip calculations with uploaded Pi records, verify playback,
+  Range requests, and downloads against disposable copies of real server footage, and browser-test
   desktop/mobile through the real hosted endpoint before committing.
 
 ### Phase 24: Native Android companion app — 🚧 PLANNED (low priority, do last)

readme.md

@@ -116,6 +116,7 @@ The browser-based phone relay was removed after real-world testing confirmed tha
 cannot reliably use the Pi's WiFi and cellular data simultaneously. A native Android companion is
 planned later instead. The next roadmap work is settings, followed by a final UI polish pass.
 After the redesign, the same interface will become a secure remote trip portal backed by the
-self-hosted server, with clear Local Pi/Remote Server labeling. Full phase history, verification
+self-hosted server, including trip replay and browsing/playing/downloading archived dashcam videos,
-notes, and current scope live in
+with clear Local Pi/Remote Server labeling and hardware-only Pi sections omitted remotely. Full
+phase history, verification notes, and current scope live in
 [PLAN.md](./PLAN.md).