UNIT 0 reading: the camera was never the problem, so Unit 1 is the wrong lever

Take ty-20261005-1201-556-0001.mp4 (75.3s) plus its log settle it. The
C920 delivers 30.0/s with ZERO gaps over 50ms and its own device stamps
agree - camera, USB and driver are clean. The pump managed 34 composites per
5s at ~141ms each, and the file holds 6.8 distinct webcam images per second
at 88.7% duplicates with no arrival hitch whatsoever. The judder is us
holding one face for 140ms and padding the rest of a 60fps container, which
is precisely what a lipreader experiences as "cutting out".

So 720p is a SHARPNESS win, not a smoothness win: it triples the bytes the
compositor stretches per render on a path already 4.4x over budget. The
exclusive camera lock stays agreed and stays queued, but it moves after the
compositor work or it makes the judder measurably worse.

The number still unexplained: the 10:01 take hit 25.6 images/s and this one
6.8, with the same scene shape (full-render split=0 elements=6 dynamic=5)
and the same 640x480 camera - composites went 29-34ms to 143-155ms between
sessions and nothing logged says why. There is no per-element composite
breakdown and no scene dump at pump start, so the next unit is measurement,
not a fix. Recorded the pump-counter overcount (13/s vs 6.8/s: one 141ms
composite lets ~4 camera frames arrive, and the counter stamps the first
epoch the resolver sees, not the frame actually drawn) so it is not
re-derived as a bug later.

ai.md

@@ -648,10 +648,32 @@ happens per submit). Regression test:
 compositor). Ragged in both = the device, the USB link, or the driver. Pump `webcam` below
 `arrivals` = the compositor missed frames the reader had already delivered.
 
-**Still unmeasured (next unit):** the camera is stuck at the C920 default 640×480 YUY2 @30 because
-all 185 `SetMediaStreamPropertiesAsync` attempts are refused under `SharedReadOnly`, so 720p MJPG is
-on the table and the compositor's headroom at ~3× the bytes is unknown. Measure first, then change
-the acquisition.
+**✅ WHAT THE FIRST REAL READING SAID (2026-10-05) — the camera was never the problem.**
+`ty-20261005-1201-556-0001.mp4` + its log: the C920 delivers **30.0/s with ZERO gaps ≥50ms**, and the
+device's own stamps are identical, so the camera, USB link, and driver are all clean. The pump did
+**34 composites per 5s (6.8/s) at ~141ms each** (worst 294ms), and the file holds **6.8 distinct
+webcam images/s at 88.7% duplicates with no arrival hitches at all**. The judder is entirely us
+holding one face for 140ms and padding the rest of a 60fps container. `resolve` is 0.1ms, so it is
+pure pixel work in the composite, not frame lookup. Two consequences, both load-bearing:
+
+- **720p is a sharpness win, NOT a smoothness win** — it triples the bytes stretched per render on a
+  path already 4.4× over budget. Schedule the exclusive lock AFTER the compositor work or it makes
+  the judder measurably worse.
+- **The 10:01 take hit 25.6 images/s and the 12:01 take 6.8, same scene shape
+  (`full-render split=0 elements=6 dynamic=5`), same 640×480 camera.** Composites went 29–34ms →
+  143–155ms between sessions with nothing logged explaining it. **There is no per-element composite
+  breakdown and no scene dump at pump start**, so the log cannot name the culprit — that gap is the
+  next thing to close, and guessing at it is explicitly out of bounds.
+
+**Counter subtlety, so it is not re-derived:** the pump's `webcam` line read 13/s while the file held
+6.8/s. Not a bug — the counter stamps a frame when the resolver FIRST sees it, and one composite takes
+141ms, so ~4 camera frames arrive during it (signature pass stamps one epoch, the actual draw uses a
+later one). The file is the truth; the pump counter is a pipeline-health signal and overcounts by
+design.
+
+**Still unmeasured:** the camera is stuck at the C920 default 640×480 YUY2 @30 because all 185
+`SetMediaStreamPropertiesAsync` attempts are refused under `SharedReadOnly`, so 720p MJPG is available
+— but see above, it is a quality win only.
 
 ### Scene compositor (TASK 4 ship step 1 — shipped 2026-08-10, plan in TASKS.md)