forgectrl pinned at the browser-proven H.264 view; jog coexistence in the record

The pin moves to forgectrl d97cb35: zero-based fragment timestamps and
the panel's clamped live-edge seek, the two faults MSE playback in a
real browser surfaced. CAMPAIGN-LOG carries the session record,
including the coexistence drill (a jog at commanded feed under both
live streams, underruns unmoved, planner buffer full). BRINGUP item 20
is down to one line: the full acceptance campaign on an image carrying
this pin.

docs/BRINGUP.md

@@ -1474,10 +1474,18 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
     measured **13.8 fps single-viewer at ~14 % CPU** (fence stall
     7-9 ms of the 64 ms render, so it is fully hidden), **9.8 fps with
     MJPEG and H.264 served at once** (stall 0), luma still bit-clean.
-    Remaining: (a) browser MSE playback of the panel's H.264 view;
+    Fourth session (2026-08-24 night, forgectrl d97cb35): MSE playback
-    (b) the stream-during-jog coexistence drill with the GPU path
+    in Chrome found the fragments carrying raw boot-clock timestamps
-    active; (c) `camera.h264-stream` and the full campaign on an image
+    and the panel's live-edge seek overshooting the one-frame buffered
-    carrying the fixes. Switches to strip a suspect layer: `FORGECTRL_NO_GPU`,
+    window; each viewer's fragments are now zero-based, the seek clamps
+    into the newest range, and a paused element is kicked back into
+    play. Verified live: the panel's H.264 view plays at 1296x972 with
+    no MJPEG fallback, and with that view plus an MJPEG viewer running,
+    a jog out and back completed at its commanded feed with the step
+    ring's underrun counter unmoved and the planner buffer full - the
+    GPU stream path and motion coexist. Remaining: the full acceptance
+    campaign (platform change: Mesa in the image) on an image carrying
+    d97cb35, which also covers `camera.h264-stream`. Switches to strip a suspect layer: `FORGECTRL_NO_GPU`,
     `FORGECTRL_NO_H264`, `FORGECTRL_NO_HW_SKIP`, plus the existing
     `FORGECTRL_NO_VPU` / `FORGECTRL_NO_NEON` /
     `FORGECTRL_NO_CACHED_BUFS`; diagnostics under `FORGECTRL_GPU_CHECK`

docs/CAMPAIGN-LOG.md

@@ -3718,6 +3718,39 @@ two encodes per frame, 33 ms, all still off-CPU). Luma stays bit-clean
 against the CPU demosaic; H.264 fragments now carry the delivered
 frame's timestamps. Bench left clean; stock service restored.
 
+## 2026-08-24: the browser plays it, and the head moves under it
+
+Fourth session, on dev 20260824140057 (the shipped image runs the
+pipelined GPU path stock: convert gpu, 13.6 fps, before any drill
+binary). Chrome driven against the panel found what byte-level checks
+could not:
+
+- The video element buffered data at t=801 s while playback sat at
+  zero: the fragments carried the raw 90 kHz boot clock. Each viewer's
+  fragments are now zero-based (the mux context subtracts the first
+  frame's clock).
+- The live-edge chaser's fixed 0.2 s back-off overshot the one-frame
+  buffered window into a gap and the element stalled at readyState 0;
+  the seek now clamps inside the newest buffered range, and a paused
+  element is kicked back into play after a seek.
+
+With the fixes (forgectrl d97cb35, drill from /tmp): the panel's Live
+button plays H.264 over MSE at 1296x972, timeline from zero, no MJPEG
+fallback, verified by script and by eye in Chrome.
+
+Coexistence, with the H.264 view live in the browser AND an MJPEG
+viewer attached: a jog out (+X 5 mm F600) and back completed at its
+commanded feed (mid-status Jog, MPos 3.619, FS 600; end Idle at
+origin), the step ring's underrun counter read 0 before and 0 after,
+and the planner buffer never left 99-100. The GPU stream path and
+motion coexist. The laser latch stayed locked and emission dark
+throughout; no armed anything.
+
+What remains of the video offload: the full acceptance campaign on an
+image carrying d97cb35 (a platform change: Mesa joined the image), and
+first light of all of it on an 8 MP machine when one exists. Bench
+left clean; stock service restored.
+
 ## Superseded status notes
 
 ### Shared machine services — remaining polish, as listed 2026-08-13

meta-forgefirm/recipes-forgefirm/forgectrl/forgectrl-pin.inc

@@ -2,5 +2,5 @@
 # only SRCREV and PV here - the image manifest leaves *-pin.inc out of the
 # layer content hash because the component entry already identifies the
 # pinned source (forgefirm-image-manifest.bbclass).
-SRCREV = "deee6a1b9a502cb7d464aeecc3e081103e4e3351"
+SRCREV = "d97cb35a270d46ef1348abb001abb64c2a275e30"
 PV = "0.1.0"