fix(web): web-layer capture cadence 10Hz → ~30Hz while recording — widget animations no longer play ~1/6 speed

The recording is 60fps but WebView2 capture was a blind 100ms DispatcherTimer = 10Hz;
each captured web frame repeated ~6x into the file caps web animation at the capture
rate, not the page's (user: 'the animation appears to be too slow').

- New CaptureScheduler (Services/CaptureScheduler.cs): per-session dispatcher timer
  that DROPS a tick while a capture is in flight (latest-wins, never queues) — the
  guard that makes a higher cadence safe: concurrent full-HD PNG CapturePreviewAsync
  calls (~10-30ms each, slow per WebView2Feedback#20) would stack CPU and publish
  stale-after-fresh. Effective cadence = max(interval, capture duration).
- Cadence: SetCaptureInterval(33) on record/stream start, (200) idle — applied via
  MainViewModel.Streaming.Operations.cs.
- De-throttle the hidden page: shared CoreWebView2Environment created BEFORE
  EnsureCoreWebView2Async with --disable-backgrounding-occluded-windows
  --disable-renderer-backgrounding --disable-features=CalculateNativeWinOcclusion.
  Off-screen WebView2 is a hidden page when the host window is unfocused/covered and
  Chromium then parks rAF and clamps timers to ~1s (WebView2Feedback#1172/#3070,
  Chrome-88 timer-throttling blog).
- Telemetry: first 30 captures per session log elapsed ms (PNG encode + decode) to
  startup.log — that decides whether ~30Hz stays or drops to ~20Hz; the FramePump
  drops frames (never time-lapses, slice 10) if UI-thread GC churn starves it.
- ONE test: CaptureScheduler_Drops_Ticks_While_Capture_InFlight_And_Resumes
  (deterministic TCS-driven, no WebView2 runtime). Suite 290/291 — sole failure the
  pre-existing compositor pixel test.
- Docs same-commit: ai.md slice 11, MyMistakes.md, HANDOFF.

References: https://github.com/MicrosoftEdge/WebView2Feedback/issues/1172
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3070
https://github.com/MicrosoftEdge/WebView2Feedback/issues/20
https://developer.chrome.com/blog/timer-throttling-in-chrome-88

ai.md

@@ -870,6 +870,35 @@ seam:** `Func<Scene?>`, `Func<SceneElement, VideoFrame?>` resolver, `Func<Compos
   submitted − dropped bytes). Full suite 289/290 (the pre-existing compositor pixel failure unchanged).
   Audio untouched (follow-up). WSL ticker-under-load reliability check still to run (informational — the
   burned counter is the judge).
+- **Slice 11 — web-layer animation ran at ~1/6 speed; capture cadence 10Hz→~30Hz + de-throttle
+  (2026-09-10, the "widget animates too slow" take):** the recording is 60fps but the WebView2
+  capture loop was a blind 100ms `DispatcherTimer` = 10Hz — a 60fps-designed widget was sampled 6×
+  under its native rate (repeated-footage slow-mo). Two stacked throttles:
+  (1) **the 10Hz cap** (unconditional, code-proven) and
+  (2) **Chromium hidden-page throttling** (`requestAnimationFrame` parked, JS timers clamped to ~1s
+  per WebView2Feedback#1172/#3070 + Chrome-88 timer throttling) whenever the app window is unfocused
+  or covered — the page is off-screen at (-5000,-5000), so it is a hidden page the moment the host
+  window loses occlusion.
+  Fixed:
+  (1) **`CaptureScheduler` (new, `Services/CaptureScheduler.cs`)** replaces the per-session
+  `DispatcherTimer`: a dispatcher timer that DROPS ticks while a capture is in flight (latest-wins,
+  never queues) — the in-flight drop is what made raising the cadence safe (concurrent full-HD PNG
+  `CapturePreviewAsync` calls would stack ~10-30ms encodes and publish stale-after-fresh). Interval is
+  owner-configurable: recording 33ms (~30Hz), idle 200ms. Unit-tested without a WebView2 runtime
+  (the ONE test: `CaptureScheduler_Drops_Ticks_While_Capture_InFlight_And_Resumes` — overlapping
+  ticks dropped, capture resumes when idle, driven by a TCS so it is deterministic).
+  (2) **de-throttle browser args**: the shared `CoreWebView2Environment` is created with
+  `--disable-backgrounding-occluded-windows --disable-renderer-backgrounding
+  --disable-features=CalculateNativeWinOcclusion` (the Electron/Streamlabs-class embedder answer for
+  occluded-window animation throttling) BEFORE `EnsureCoreWebView2Async`.
+  (3) **cadence hook**: `MainViewModel` sets `SetCaptureInterval(33)` on record/stream start and
+  `(200)` on stop (`MainViewModel.Streaming.Operations.cs`).
+  (4) **capture-cost telemetry**: first 30 captures per session log elapsed ms to startup.log —
+  PNG-encode+decode cost decides whether ~30Hz stays or drops to ~20Hz; the FramePump drops frames
+  (never time-lapses, slice 10) if UI-thread GC churn starves it, so the cost is observable.
+  Full suite 290/291 passing, the sole failure the pre-existing compositor pixel test. The web-overlay
+  transparency verification (the first-capture diagnostic bound to about:blank) and the audio-silence
+  item remain open push-gate items — both untouched by this slice.
 - **Stop ordering matters:** `StopAsync` stops the encoder — since slice 10 it FLUSHES the pending
   queue (`Channel.TryComplete` → drain writes the leftovers, closes stdin → EOF → ffmpeg finalizes+exits;
   an accepted frame is never lost) — **before** awaiting the loop. The old reverse-order deadlock was