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.

MyMistakes.md

@@ -923,3 +923,23 @@ fake-probe delay-recorder test now pins real-time video pacing
 (`AlertClipDecoderTests.AlertClipDecoder_PacesVideoFramesToTheProbedFrameRate`). Rule added to the
 list above: (4) if output arrives but the USER still reports no/motionless picture, check pacing
 before decode — count the bytes/s against wall-clock, don't re-audit the codec.
+
+**RULE (5) — the last hop is a hop. A producer that hands over a correct frame has still
+delivered nothing.** The 2026-09-26 alert hunt burned four builds (89/90 + two more) proving
+the video was PERFECT: real h264, 240 frames, bright pixels at every timestamp, byte-identical
+to the creator's source file, opaque `a255` frames logged every second into both the preview
+and the compositor resolver. The box was blank because `PreviewPane.xaml`'s per-element
+`Image` is `Collapsed` unless a DataTrigger says otherwise, and nobody had ever written the
+`IsAlertBox` one. Two lessons, both expensive:
+- **"It decodes, it's handed over, it's still invisible" ⇒ stop auditing the producer and
+  audit the CONSUMER'S VISIBILITY.** Bytes existing is not pixels being drawn. Diff the two
+  consumers' behaviour: chat box rendered, alert box didn't — that asymmetry was the whole
+  clue, and every per-frame log said "healthy".
+- **A test whose fakes replace the failing seam will pass forever.** `AlertLayerVideoTests`
+  drove `RenderFrame` with a fake decoder and was green through the entire outage; the decode
+  test used a fake process; nothing ever crossed the XAML. When a feature's output is
+  *displayed*, the test must build the real display path (`AlertBoxPreviewVisibilityTests`
+  drives the real `MainWindow`+`PreviewPane`). And when the symptom is "nothing appears",
+  the honest test asserts on the CONSUMER (is the Image Visible / are the canvas pixels
+  different), never on the producer's own counters.
+- Corollary: never trust "the data arrived" as a root cause. Ask what draws it.