TASK 47: draw the alert clip — the preview Image was Collapsed for AlertBox

Four builds (89/90 + two) burned proving the alert video was PERFECT: real h264
1280x720, 240 frames decoded, alert audio in the live mix, and the shipped asset
byte-identical (md5 0ee1f496…) to the creator's llamacasty-dancingLlama-thankyou.mp4
with every sampled frame full bright content. Build 90's new diagnostics then showed
the frame reaching BOTH consumers every second for the whole clip —
`Alert preview: frame=680x200 a255` and `Output resolver: frame 680x200
playing=True` — an opaque, correctly-sized frame, handed over and never seen.

Root cause: Controls/PreviewPane.xaml keeps the per-element Image Collapsed unless a
DataTrigger fires, and there was no IsAlertBox trigger (only IsImageSource / IsChatBox /
IsWebSource / IsWebcam). The alert box's Image was therefore Collapsed forever. Chat
boxes rendered because they HAVE a trigger — that asymmetry is the whole clue, and it
is why removing/re-adding the layer could never fix it.

Fix: an IsAlertBox DataTrigger beside the IsChatBox one.

Two Good Dog tests, because the existing fakes had been hiding this:
- AlertBoxPreviewVisibilityTests (red `Expected: Visible / Actual: Collapsed`, now
  green) drives the real MainWindow + PreviewPane and asserts the bound Image is
  Visible — the first alert test that crosses the XAML at all.
- AlertClipOutputTests is the first test in the repo to run a REAL codec: pinned ffmpeg
  generates a clip, the real AlertClipDecoder + AlertOverlayLayer + SceneCompositor
  composite it, and the box rect must be a colourful picture that DIFFERS from idle. It
  passed while the feature was broken in the app — which is exactly why it was needed:
  it exonerated decode+layer+compositor and pointed the hunt at the last hop.

Also keeps the two once-per-second alert diagnostics (resolver + preview) that settled
it, pending the creator's call on whether to keep them.

Notes: the pinned BtbN ffmpeg has no libx264, so the test clip is -c:v mpeg4.
SceneCompositor.Render fills its base with opaque black, so the test compares against an
idle render rather than counting non-zero bytes. MediaSource has the same missing trigger
in PreviewPane.xaml — left unfixed as out of scope, noted in HANDOFF.

Full suite 324/324. Lesson recorded in MyMistakes.md rule (5): a producer that hands over
a correct frame has still delivered nothing — when output arrives and the user still sees
nothing, stop auditing the producer and audit the consumer's VISIBILITY.

TASKS/task-47-alert-videos.md

@@ -211,4 +211,47 @@ not decode.**
   queued, unchanged.
 - The alert-store folder (`Apps_Commands`-style per-clip assets) stays out of scope —
   the current model is read-at-play from a path, per the creator's "never store the
-  video" ruling.
+  video" ruling.
+## Take three — the video was never DRAWN (2026-09-26, the real one)
+
+Build 89 and build 90 both decoded the clip perfectly and showed nothing. The build-90
+diagnostics settled it in one run, and the answer was NOT in the video pipeline at all:
+
+```
+Alert clip start: box ce2532a1… path '…ytLive-alert-941785b0….mp4' 680x200
+Alert preview: box ce2532a1… frame=680x200 a255          ← opaque, right size, every second
+Output resolver: alert box 'ce2532a1…' frame 680x200 (visible=True playing=True)
+Alert clip end: … frames=240 audioChunks=156 failed=False
+```
+
+The frame reached BOTH consumers, opaque and correctly sized, for the whole 10s. The clip
+itself is fine — the shipped asset (`AlertDefaultVideoAssetId` = 941785b0…, md5
+`0ee1f4960dd3b23dee5930a2af79d410`) is byte-identical to the creator's original
+`Downloads\llamacasty-dancingLlama-thankyou.mp4`, h264 1280x720 10s, and every sampled
+frame is full bright content (mean ~470/255, 100% non-zero bytes).
+
+**Root cause: `Controls/PreviewPane.xaml`.** The per-element `Image` is `Collapsed` by
+default and only becomes Visible via DataTriggers for `IsImageSource` / `IsChatBox` /
+`IsWebSource` / `IsWebcam`. There was no AlertBox trigger, so the alert box's Image stayed
+Collapsed forever — the bound frame was never rendered. Chat boxes showed because they
+HAVE a trigger; that asymmetry is why "the chat window works but the alert layer doesn't"
+looked like a decode problem. Removing/re-adding the layer could never fix it.
+
+Fix: an `IsAlertBox` DataTrigger next to the `IsChatBox` one.
+
+Two Good Dog tests, because the fakes had been hiding this:
+
+- `AlertClipOutputTests.AlertClip_RealDecode_PaintsPixelsInsideTheAlertBoxRect` — the
+  first test in the repo that runs a REAL codec: generates a clip with the pinned ffmpeg
+  (`mpeg4`, not libx264 — the pinned BtbN build has no x264), drives the real
+  `AlertClipDecoder` + real `AlertOverlayLayer` + real `SceneCompositor`, and asserts the
+  box rect is a COLOURFUL picture that DIFFERS from the idle canvas. It passed even while
+  the feature was broken in the app, which is exactly why it was needed: it exonerated
+  decode+layer+compositor and pointed the hunt at the last hop. Note the compositor fills
+  its base with opaque black, so "any non-zero byte" is NOT a pass — compare against idle.
+- `AlertBoxPreviewVisibilityTests.AlertBox_HandedAFrame_IsDrawnInThePreviewPane` — real
+  `MainWindow` + real `PreviewPane`, an AlertBox handed an opaque `WriteableBitmap`, assert
+  the bound `Image` is `Visible`. Red with `Expected: Visible / Actual: Collapsed` before
+  the fix, green after.
+
+Full suite 324/324.