fix(web): wipe background-image too — the widget's black void is a CSS backdrop gradient, not a color

The 15:34 take's box interior is the widget's OWN full-canvas opaque paint — a
black void with wide content strips at the top/bottom and a right-edge bar —
arriving AFTER the first-second blank-transparent dumps. A background-color-only
!important wipe (b4bba4b) can't touch it because CSS gradients/backdrops are
background-IMAGE, not background-color.

OBS's fix for this exact symptom is background-image:none (obsproject/obs-studio#6659:
"set the CSS for html and body to background: none !important"). Injection now wipes
background-image:none!important on html,body,html * alongside the color wipe; HTML
overlay art (<img>/DOM/CSS shapes) survives — that is browser-source semantics.

Also re-arms WidgetDumpRemaining=5 ~30s after nav so the next take dumps the real
document INSIDE the recording window (the previous dumps proved blank at +1s and
missed the later backdrop paint).

9/9 WebView2Manager tests, 0 warnings.

HANDOFF.md

@@ -8,37 +8,30 @@ audio-silence are addressed).
 
 ## ACTIVE THREAD (ONE problem at a time)
 
-**Web-uri transparency — branch (a) CONFIRMED and FIX-APPLIED, awaiting the verify take.**
-The 12:54/13:50 dumps proved the REAL widget document captures TRANSPARENT
-(`%TEMP%\ytLive-web-8d7234ec…-w1..5.png` alpha max 0/logged alpha 100% zero) YET the
-recording kept showing a black opaque box over the element rect (1231,679,705,396 — crisp
-edges, interior mean RGB ≈(1,6,13), NOT the desktop). Conclusion: the OLD inline
-`element.style.background='transparent'` injection only holds while the page has nothing
-to paint; once the widget connects and repaints a container background-COLOR, the capture
-re-opaques → black box. That is the OBS-solved class ("all web-uri resources paint their
-own background").
+**Web-uri transparency — second hardening applied (background-image wipe), awaiting take.**
+The 15:34 take: the recording's box interior is the widget's OWN full-canvas opaque paint
+(bright content strips at top/bottom + right bar over a black void) — NOT desktop, NOT a
+compositor blend. The real-document dumps showed blank-transparent at +1s and the page's
+backdrop appears later; a background-COLOR-only `!important` wipe (b4bba4b) leaves CSS
+background-IMAGE (gradient/backdrop) intact — the OBS answer is `background: none
+!important`, background-image too (obsproject/obs-studio#6659).
 
-**Slice 14 change (commit target):** `WebView2Manager.TransparentBackgroundScript` is now a
-pre-parse `<style id='ytl-transparent-bg'>` wiping `background-color:transparent !important`
-on `html,body,html *` (background-images/art survive — only background-COLOR targeted).
-Idempotent by element id; `!important` outranks every page rule (OBS forums 2016 `body {
-background-color: rgba(0,0,0,0) !important }` + div variant, woahtech OBS custom-CSS guide —
-both cited in the commit message and `MyMistakes.md`).
-- `internal const` + regression test `TransparentBackgroundScript_Is_A_Important_Element_Wide_Wipe`
-  (asserts element-wide `!important`, style-element form, and that the losing inline
-  `.style.background=` form is gone).
-- Build 0 warnings; 9/9 WebView2Manager tests pass.
+**Slice 15 (commit target, the fix):**
+- `TransparentBackgroundScript` now also wipes `background-image:none!important` on
+  `html,body,html *` (gradients/backdrops die; `<img>`/DOM art survives — OBS semantics).
+- `NavigateCompleted` re-arms `WidgetDumpRemaining = 5` ~30s in, so this take dumps the
+  real document INSIDE the recording window (the missing evidence last time).
+- Test extended (asserts `background-image:none!important` present, weak inline form absent).
 
 ## THE ONE REMAINING STEP (verify, no further analysis)
 
-1. User REPLACES the app (build is current) and records the Live scene, widget animating,
-   like the 12:54/13:50 takes.
-2. Verdict: element rect shows scene bg with widget art over it (NO black box) → transparency
-   C LOSED, push gate #1 clears. If it still shows a solid black box you can SEE at a glance
-   inside the widget's 705×396 area, bring it + then (and ONLY then) audit what other layer
-   paints that rect in the composite — the web capture has been exonerated twice.
-3. Then the queued layer-order-save bug (dragging an element over another doesn't persist
-   `SortOrder`) is the next single use case.
+1. User records the Live scene, widget animating (pre-record ~35s so the 30s re-arm dump
+   fires mid-take).
+2. Verdict: element rect shows the scene backdrop behind the widget art (no black box/void)
+   → transparency CLOSED, push gate #1 clears. If a black void persists BEYOND a visible
+   background-image, it's not background painting and only chroma-key remains — bring the
+   take and we do the compositor key, not more capture investigation.
+3. Then the queued layer-order-save bug (reorder doesn't persist `SortOrder`) is next.
 
 ## Other threads (paused)