docs(observation): document durable sessions and viewer lifecycle

docs/01_IMPLEMENTATION_PLAN.md

@@ -3,7 +3,7 @@
 This plan supersedes the app-dependent experiment order in the reference Bible.
 Each gate produces evidence and an explicit GO, PAUSE or BLOCKED result.
 
-## Live checkpoint — 2026-07-15
+## Current checkpoint — 2026-07-17
 
 | Stage | Result |
 | --- | --- |
@@ -15,8 +15,11 @@ Each gate produces evidence and an explicit GO, PAUSE or BLOCKED result.
 | Stage 4 artifacts/flows | GO — bounded capture, hashes and negative control |
 | Stage 5 point cloud | GO — raw-LZ4 protobuf, 1,140 live frames decoded |
 | Stage 5 pose | GO — 1,215 live frames decoded and motion-correlated |
-| Stage 5 camera | GO (discovery) — left/right RTSP/H.264 preview observed; runtime adapter pending |
-| Stage 6 live viewer | GO — React console, Foxglove cloud/path and Mac latency metrics |
+| Stage 5 camera | GO (live) — left/right RTSP/H.264 preview observed, read-only runtime adapter and physical UI acceptance completed |
+| Stage 6 live viewer | GO — React Control Station, embedded self-hosted Rerun cloud/trajectory and Mac pipeline metrics |
+| Stage 7 observation archive | GO (point/pose) — durable catalog, recovery, background RRD preparation, saved-session timeline and atomic playback verified |
+| Stage 7 recorded cameras | GO (contract), acceptance pending — acquisition-owned fMP4 archive and player are implemented/tested; no real archived K1 camera session exists yet |
+| Stage 8 product storage | PAUSE — retention, replication, encryption, capacity monitoring and long-run browser/WASM stress remain deployment gates |
 
 USB project copying remains optional ground truth rather than a blocker for the
 now-verified network path. Owner-operated LixelGO traffic verifies the MQTT
@@ -24,10 +27,14 @@ start/stop mapping and RTSP camera transport. MQTT control publishing remains
 deliberately deferred because complete request/save/rollback semantics are not
 yet modeled and the physical button remains a known-safe fallback.
 
-The Stage 6 alpha uses a bounded raw-first bridge: loss in the visualization
-queue cannot discard MQTT evidence. Acceptance is replay of the full captured
-scan followed by a live ideal-LAN run with measured host pipeline latency.
-Sensor-to-display latency remains a separate clock-correlation test.
+The Stage 6 live path uses a bounded raw-first bridge: loss in the visualization
+queue cannot discard MQTT evidence. Stage 7 adds an independent durable
+observation-session lifecycle. Completed or recovered native captures are
+prepared once by a bounded backend worker into digest-bound RRD/cache-v6 and
+camera-manifest generations; a browser replay request never performs conversion.
+The saved scene, controller and timeline remain hidden until the complete RRD
+range and every declared camera pass admission. Sensor-to-display latency and
+camera/LiDAR sensor-clock alignment remain separate correlation tests.
 
 ## Stage 0 — repository and host baseline
 
@@ -213,4 +220,6 @@ useful stream is decoded or structurally identified.
 - automated scan-button electronics;
 - OpenWrt/monitor-mode infrastructure;
 - firmware or internal-Linux analysis;
-- camera branch if no external frame stream is evidenced.
+- physical end-to-end replay acceptance for newly archived left/right cameras;
+- long-running large-session WebViewer/WASM memory telemetry;
+- production retention, replication, encryption and cross-platform packaging.