fix: first native launch since refactor crashed — 3 stacked faults, all closed; RoundClip 'known failure' root-caused and green

User launch (2026-09-01 19:07) NRE'd in MainViewModel ctor:
1. SceneGraph (TASK 31) was 'null!'-declared, assigned mid-ctor, but Scenes is touched
   ~120 lines earlier — field-initialized now.
2. LeftPanel extraction (c9fd1bd) moved StaticResource users (EyeButton/EyeIconStyle)
   into a UserControl while the styles stayed window-scope — invisible at parse time;
   moved to Themes/Controls.xaml (app scope, the existing rule). Full audit: these were
   the only two offenders (grep of Controls/*.xaml StaticResource keys vs app dictionary).
3. RoundClipInteractionTests — the second 'known failure' the map never explained: it
   was two stale-test layers (window.FindName across the new UserControl namescope +
   VisualTreeHelper.HitTest, which returned the IsHitTestVisible=False WebViewHostPanel
   overlay for EVERY point; UIElement.InputHitTest — the real input pipeline — shows the
   corner IS grabbable in both Traditional and Round). Test fixed, no product bug.
Verified: clean rebuild 0 warnings; app boots (log shows full MainWindow loaded; user
clicked + closed, zero new exceptions; real DB Webcam row = the genuine C920, untouched);
RoundClip + 6 RealApp classes pass natively per-class.
Docs: ai.md known-failure note → 246/247 (audio only); TASK 31 verification paragraph
corrected ('cannot run headless' overstated — per-class Windows-host vstest runs them);
MyMistakes: InputHitTest-vs-VTH recipe + namescope/app-style + shared-log facts.
Spin-guard citations: WPF Visual Tree Overview (InputHitTest vs VisualTreeHelper hit
semantics) + XAML namescope docs, learn.microsoft.com.

MyMistakes.md

@@ -89,3 +89,38 @@ paths to `\\wsl.localhost\Debian\…` and throws "not a valid application for th
 OS" when handed a Linux ELF ffmpeg. So never plan to have dotnet exec a Linux
 ffmpeg here; verify the contract with shell/python instead, and leave the
 CLR→real-ffmpeg run to the native Windows suite.
+
+## WPF hit-test truth in tests: `UIElement.InputHitTest`, NOT `VisualTreeHelper.HitTest`
+
+(2026-09-01, the RoundClip "known failure" post-mortem — a failure the map carried as
+"not a regression" for weeks without ever recording WHY.)
+
+**The trap:** `VisualTreeHelper.HitTest(window, pt)` returned the window's
+`WebViewHostPanel` overlay (`IsHitTestVisible="False"`, `Opacity=0`, ZERO children) for
+EVERY point in the window — so a "corner is grabbable" assertion could never pass, and
+it looked like a real interaction bug. The actual input pipeline (`UIElement.InputHitTest`,
+what Mouse routing uses) correctly returned the element's Grid at elem-center/corner-in/
+corner-exact and fell through to CanvasGrid just past the corner. The product was fine;
+the TEST was probing an API that doesn't model input semantics.
+
+**Rule:** any test asserting "where does a click land" uses `window.InputHitTest(pt)` +
+`IsDescendantOf` — never `VisualTreeHelper.HitTest`.
+
+**Diagnosis recipe (how the lie was caught in ~3 probe cycles, no guessing):** add a TEMP
+probe `[Fact]` in the RealApp collection that hit-tests a spread of points
+(elem-center / corner-in / corner-exact / corner-out / bg-center) and `Assert.Fail`s with a
+composed dump: per-point VTH hit + `InputHitTest` hit + ancestor chain (`GetParent` walk
+with `#Name`) + panel properties (`IsHitTestVisible/Opacity/children/actual size`) +
+`TranslatePoint` origins. Run the class alone, read the message, delete the probe.
+
+**Two sibling facts learned the same session (record-once):**
+1. A UserControl owns its own XAML namescope — after extracting a region out of a window,
+   `window.FindName("InnerPart")` returns null; resolve the UserControl by its window-level
+   name, then `pane.FindName("InnerPart")`. And window-scope STYLES are invisible to a
+   UserControl's `StaticResource` at parse time — move such styles to `Themes/Controls.xaml`
+   (the app-scope rule exists for this).
+2. Per-class `dotnet.exe vstest` from WSL DOES execute the RealApp/`MainWindow` tests fine
+   (they passed natively 2026-09-01) — only the FULL suite hangs (WASAPI startup). And the
+   test process shares `%APPDATA%\ytLlive\startup.log` with the real app: lines like
+   `camera 'test-camera' failed` are test noise, not DB state — to check pollution, query
+   the DB directly (`python3 sqlite3`, `SELECT DeviceId FROM Webcam`), not the log.