UNIT 0: make a dropped webcam frame measurable, not just inferable

The creator is DHH and lipreads their own recordings, so a webcam that
judders is an accessibility defect, not a polish item. Take
ty-20261005-1001-821-0001.mp4 holds 25.6 distinct webcam images/s against
the camera's 30fps with 281 gaps of 50-100ms - roughly one hitch in five -
in a file that muxes flawlessly. Nothing in the app could see that: rawvideo
carries no per-frame timestamps (ffmpeg stamps by ARRIVAL at the declared
60fps), and the stats line divided every average by the number of frames
SUBMITTED, which deadline padding always fills to the full target. So the
pump reported "300/300 frames, avg render 12.4ms" while producing 60
distinct composites.

Helpers/FrameCadence.cs is one pure counter fed from three points:
MediaCaptureFrameSource logs the device's own SystemRelativeTime stamps
against our arrival times (TryAcquireLatestFrame keeps only the LATEST
frame, so falling behind is silent by design), and FramePump logs the
distinct webcam Epoch values that reached a composite. Read together they
name the culprit - device/USB, our reader, or our compositor - instead of
guessing. Render/resolve/wait now divide by the real render count, and
"frames per 5s from R renders" is the duplicate-on-lag ratio stated
honestly.

An out-of-order timestamp counts as a frame but produces no gap and does not
become the next interval's reference, so one bad stamp cannot invent a
multi-second hitch twice.

Also corrects a stale ai.md line (the "webcam renders at ~18fps" figure
came from a different session and counted every newly rendered layer) and
re-records the background-removal ruling as permanently out. Records the
agreed-but-unbuilt Units 1-2, the no-fallback-camera ruling, and the
SetFormatAsync dead end found by probing the 19041 projection.

Suite 402/402, 0 warnings. The one red, LayerReorderPersistenceTests'
RealMouseDrag, fails identically on a stashed clean tree - it needs an
interactive desktop session this shell lacks.

TASKS.md

@@ -156,6 +156,19 @@ second encoder path needing a "redirect". Record+simulcast is one ffmpeg with tw
   adopts a solo camera as default. TASK 26's app-wide gate superseded by creator directive. The App
   Settings webcam selector is now **TASK 40 Unit A** (plan saved 2026-09-22). Remaining next slice
   (user-queued): static (+) catalog rows (Background, YouTubeEvent, quoted labels) with reason-greying.
+- **🔶 Webcam cadence → resolution — IN PROGRESS, creator-queued 2026-10-05** (DHH/lipreading: the
+  webcam judders, ~1 hitch in 5, invisible in the output file). **UNIT 0 shipped** (counters +
+  `Helpers/FrameCadence.cs`; see `ai.md` → "Frame cadence"). **Needs a creator recording before the
+  next unit.** Remaining units, all agreed 2026-10-05, one Good Dog test each:
+  - **Unit 1:** `MediaCaptureSharingMode.ExclusiveControl` + MJPG ≥30fps up to 1280×720 via the
+    existing `SetMediaStreamPropertiesAsync` path (refused only because `SharedReadOnly`); same-camera
+    `SharedReadOnly` retry. **The creator reversed the ban on taking an exclusive camera lock.**
+    API probe already done — see HANDOFF.md, incl. the `SetFormatAsync` dead end.
+  - **Unit 2:** blinking amber **"SD" badge**, preview only, never in the recording/stream, when a
+    better format was available and not obtained. Top-right corner, or the 1:30 rim point when the
+    clip is round.
+  - ⛔ **No fallback-camera feature, ever** — *"that's bypassing the user's explicit choice."*
+  - ⛔ **No background removal** — re-affirmed out 2026-10-05.
 - **TASK 40 — App Settings round** — plan saved 2026-09-22 (`TASKS/task-40-app-settings-round.md`),
   four units, one Good Dog test each: **A** active web camera section under Recordings (Change…
   sub-menu = live enumeration incl. vcams; Tune… config dialog via `ICameraControlProbe`, live-only
@@ -357,7 +370,9 @@ See [`TASKS/research-youtube-api.md`](TASKS/research-youtube-api.md) — authori
 These were explicitly ruled out:
 
 - **D3D11 swap compositor** (superseded by software compositor; TASK 3 item 16)
-- **Background removal** (ONNX/DirectML; TASK 3 item 19)
+- **Background removal** (ONNX/DirectML; TASK 3 item 19) — ⛔ **re-affirmed out 2026-10-05**: *"no - not
+  doing it. the note is correct and accurate."* A vcam app does it free; an in-app model is a runtime,
+  a GPU/driver matrix, and per-scene lighting tuning. **Never reopen without a new ruling.**
 - **OBS-style source expansion** (game capture, browser source, media playlist, VLC, color-key, MIDI — the minimal source set is deliberate; creators who need more have graduated to OBS)
 - **Multi-layout** (auto-save, single layout; multi-layout = OBS territory)
 - **Cross-process stream resume** (API makes it impossible; creator ruling 2026-09-01)