alert ticker: draw it inside the Stream Alerts box, not as a top-edge bar

Creator 2026-09-26: "the ticker should appear over the stream alerts video, not over
the entire preview window". It was a GLOBAL 1920x48 bar blitted last at a hardcoded
(0, 0) -- it covered the whole preview width, not the alert video.

The strip is now rendered at the alert box's own size and the box's origin travels on
the frame in a new VideoFrame.Placement ((int X, int Y)?). OriginX/OriginY default to
0 when Placement is null, so every full-canvas overlay (the branding flash) is
unaffected. Every ticker blit site now reads tickerFrame.OriginX/OriginY instead of a
literal 0, 0 -- SceneCompositor x2 and FramePump's static-bake Overlay path -- and
PreviewPane.xaml's AlertTickerElement binds the same rect (AlertTickerLeft/Top/
Width/Height), so the preview cannot drift from the recording the creator is judging.

Why the position rides on the frame rather than in a full-canvas frame: a 1920x1080
overlay is 8.3MB of large-object-heap garbage per tick, ~2.5GB churned over one 10s
alert at 30fps. A box-sized strip is ~370KB. The branding flash does render
full-canvas but RECYCLES one 8MB buffer and bumps Epoch, so it never allocates per
frame; the ticker allocates per call, so it has to stay small.

Also fixed: CopyStrip now clips ROWS to the target height. The pill rasterises at its
natural 48px, so an alert box shorter than that would have written past the end of the
target buffer once the strip became box-sized.

No alert box in the scene now means no ticker at all -- there is no global position
left for it, and this is the guard against the old bar quietly coming back.

Tests (3 new facts, 27 in the file):
  ComposedOutput_PutsTheTickerInsideTheAlertBox_NotAtTheTopEdge -- renders through
    the real SceneCompositor and asserts the pixels land at (620, 430) and NOT at the
    top-left corner. The creator is judging compositing from local recordings, so the
    OUTPUT side is the side that needed proving.
  ASceneWithNoAlertBox_PublishesNoTicker
  ABoxShorterThanTheStrip_ClipsRowsInsteadOfOverrunning
Updated AlertLayer_PublishesARealTickerFrameToThePreviewSink, which asserted the old
1920 width from a box with no geometry (defaulted to 1px); it now uses the product's
own default box (680x200 at 620,430, MainViewModel.Sources.cs:54-57) and pins the
frame size and origin.

Full suite 367/367.

ai.md

@@ -1724,14 +1724,34 @@ published decisions (recorded in `TASKS/task-43-native-alerts.md`):
   forwards to the mixer sink scaled by `volume × fade`.
 - **Alert ticker (announcement strip):** `AlertTickerFrame` (in the layer) composes
   "Author — Kind · amount" and hands it to `Services/Compositor/AlertTickerRenderer.cs` —
-  a 1920×48 strip rasterized **on the UI thread once per text** (cached, unpremultiplied
+  a strip rasterized **on the UI thread once per text** (cached, unpremultiplied
   straight-alpha pill) then positioned by pure byte-math per call, so the pump calls it
   from its own thread with no locking. **It is a dynamic overlay, NEVER baked** (the
   social bar IS baked into `BakeStaticBase`): `SceneCompositor.Render` +
-  `CompositeLayers` take a trailing `tickerFrame` (blitted last at 0,0) threaded from
+  `CompositeLayers` take a trailing `tickerFrame` threaded from
   `FramePump._alertTicker` (`Func<VideoFrame?>` ctor seam) through
   `RenderScene`/`RenderFull` and **mixed into `BuildFullRenderSignature`** so a scroll
   changes the cache key. Toggled by `AlertShowTicker`.
+  - **It draws INSIDE the Stream Alerts box (creator ruling 2026-09-26).** Was a global
+    1920px bar pinned to the top edge: *"the ticker should appear over the stream alerts
+    video, not over the entire preview window"*. The strip is now rendered at the
+    **alert box's own size** (`AlertTickerRenderer.Render(..., width, height)`, defaults
+    still 1920×48) and the box's origin rides on **`VideoFrame.Placement`**
+    (`(int X, int Y)?`, with `OriginX`/`OriginY` = 0 when unset). Every blit site reads
+    `tickerFrame.OriginX/OriginY` instead of a literal `0, 0` — `SceneCompositor` ×2 and
+    `FramePump`'s static-bake `Overlay` path. The preview binds the same numbers
+    (`AlertTickerLeft/Top/Width/Height` → `AlertTickerElement`'s `Canvas.Left/Top` +
+    `Width`/`Height`), so preview and output cannot drift — the same guarantee as the
+    branding credit. Product default box is **680×200 at (620, 430)**
+    (`MainViewModel.Sources.cs`); height is clamped to the natural 48px strip.
+    **No alert box in the scene ⇒ no ticker at all** — there is no global position left.
+  - **Why the position travels on the frame, not in a full-canvas frame:** a 1920×1080
+    overlay is 8.3MB of large-object-heap garbage per tick — ~2.5GB churned over one 10s
+    alert at 30fps. A box-sized strip is ~370KB. The branding flash *does* render
+    full-canvas, but it **recycles** one 8MB buffer and bumps `Epoch`, so it never
+    allocates per frame; the ticker allocates per call, so it must stay small.
+  - `CopyStrip` clips **rows** to the target height: the pill rasterises at its natural
+    48px, so a box shorter than 48px would otherwise write past the end of the buffer.
   - **Three display methods** (`Source.AlertDisplayMethod`, DB column, panel "Display"
     selector): `TickerScroll` (marquee), `Flash` (0.5s on / 0.5s off), `Solid` (centred,
     still). The marquee is paced in **reads per alert** — `TickerReadsPerAlert = 3`
@@ -1739,13 +1759,14 @@ published decisions (recorded in `TASKS/task-43-native-alerts.md`):
     old fixed `140px/s` took ~17s per pass, so a 10s alert showed the message once.
     Same convention as the incumbent (Streamlabs: "Alert Duration" + "Text Delay", not a
     scroll-speed slider). Flash's off half returns null.
-  - **A global overlay needs its own preview element, not a `Source`.** The strip is
-    master-width, so it can't ride a per-element `Image`; a frame-pump-only producer
-    reaches the stream and never the creator's preview. `AlertOverlayLayer` takes a
+  - **A ticker still needs its own preview element, not a `Source`.** It is a frame-pump
+    producer, so it never rides a per-element `Image`; `AlertOverlayLayer` takes a
     `tickerPreviewSink` and publishes from `RefreshAlertPreviews()` (UI thread only —
     the pump thread must never touch a `WriteableBitmap`); the VM writes it into one
-    reused `WriteableBitmap` (`AlertTickerImageSource`/`AlertTickerVisible`) bound to a
-    global `AlertTickerElement` in `PreviewPane.xaml`, mirroring `SocialBarElement`.
+    reused `WriteableBitmap` (`AlertTickerImageSource`/`AlertTickerVisible`) bound to
+    `AlertTickerElement` in `PreviewPane.xaml`, mirroring `SocialBarElement`. The rect
+    is re-raised on **every** published frame, not just on a bitmap resize, so a box
+    moved or resized mid-alert tracks live.
   - **Two measurement traps here:** a seamless marquee never goes blank (a wrapped copy
     enters as the pill clears), so count a pass by the pill's leading edge resetting, not
     by an empty frame; and the run is phase-started half a frame in, or the first