fix(web): harden the transparency injection to the OBS-standard element-wide !important wipe

The real-widget dumps (12:54/13:50) proved the OLD inline
element.style.background='transparent' injection holds only while the page has
nothing to paint: the capture was alpha-transparent, yet the recording showed a
black opaque box over the whole element rect (1231,679 705x396) once the widget
connected and repainted a container background-COLOR — CapturePreviewAsync always
honors page CSS (MicrosoftEdge/WebView2Feedback specs/BackgroundColor.md), so any
page-painted background wins over DefaultBackgroundColor.

This is the OBS-solved class (all web-uri resources paint their own background):
browser sources use a Custom CSS override, and the decade-validated formula for
arbitrary pages is a pre-parse <style> with 'background-color: transparent
!important' — https://obsproject.com/forum/threads/translucent-transparent-browser-source.59549/
('body { background-color: rgba(0,0,0,0) !important }') plus the div-level variant
for stubborn widgets (woahtech.com OBS custom-CSS guide).

Injection is now an idempotent pre-parse style element wiping background-color on
html,body,html * with !important (outranks every page rule, runs before page parse
via AddScriptToExecuteOnDocumentCreatedAsync). Only background-COLOR is targeted —
background images and widget art survive. Regression test asserts the element-wide
!important form and that the losing inline form is gone.

9/9 WebView2Manager tests, 0 warnings.

Services/WebView2Manager.cs

@@ -155,12 +155,30 @@ public sealed class WebView2Manager : IDisposable
     // fight (page styles ran first). CapturePreviewAsync "will always honor a webpage's
     // background content" (MicrosoftEdge/WebView2Feedback specs/BackgroundColor.md), so a
     // transparent capture REQUIRES the transparency to be in place before the page paints.
-    private const string TransparentBackgroundScript =
-        "document.documentElement.style.background='transparent';" +
-        "document.documentElement.style.overflow='hidden';" +
-        "document.documentElement.style.margin='0';" +
-        "if(document.body){document.body.style.background='transparent';" +
-        "document.body.style.overflow='hidden';document.body.style.margin='0';}";
+    //
+    // The OLD inline `element.style.background='transparent'` form lost to any page CSS:
+    // a widget that paints a background-COLOR on a container (or html/body with stronger
+    // specificity) after connect re-opaques the capture → the "black opaque box" in the
+    // recording while the early frames were transparent. This is a solved problem in the
+    // overlay ecosystem — OBS browser sources use a Custom CSS override and the decade-
+    // validated formula for arbitrary pages is a `!important` background-color wipe
+    // (OBS Forums 2016 "body { background-color: rgba(0,0,0,0) !important }",
+    // https://obsproject.com/forum/threads/translucent-transparent-browser-source.59549/,
+    // and the div-level variant for stubborn widgets, woahtech.com OBS custom-CSS guide).
+    // A `<style>` node injected before parse, with `!important`, outranks every page rule
+    // (only an author !important beats a later document-order !important; ours runs first).
+    // Only background-COLOR is wiped — background images and the widget art survive.
+    internal const string TransparentBackgroundScript =
+        "(function(){" +
+        "if(document.getElementById('ytl-transparent-bg'))return;" +
+        "var s=document.createElement('style');" +
+        "s.id='ytl-transparent-bg';" +
+        "s.appendChild(document.createTextNode(" +
+        "'html,body{background-color:transparent!important;margin:0!important;overflow:hidden!important;}'" +
+        "'html,body,html *{background-color:transparent!important;}'" +
+        "));" +
+        "(document.head||document.documentElement).appendChild(s);" +
+        "})();";
 
     private async Task InitializeAsync(Source source, WebSourceSession session)
     {