feat(stream): retry a dropped push instead of ending the session (TASK 32·1)

A dead encoder used to run the whole stop path, so a one-second blip ended the broadcast. Now a dropped
push is relaunched against the same ingest while the broadcast is still alive.

- `Services/StreamRetryPolicy.cs` — immediate, +1 s, +2 s, +3 s. Minimum waits on purpose (creator
  ruling): YouTube's grace is short, so every second not pushing is grace spent.
- `Services/StreamRecovery.cs` — the loop, with the audio pipe recreated before every attempt (its
  server is single-instance and unusable after the old client dies, so a naive relaunch fails on a
  missing input). After a push comes up it asks the API whether the broadcast survived: "complete"
  ends recovery as `BroadcastComplete` instead of showing a live sign over a dead stream; an API
  hiccup counts as recovered rather than ending a healthy session.
- `FramePump.EncoderFailed` — a dead push is recoverable; a compositor fault still goes through
  `Failed` and ends the session, because retrying it would loop.
- `MainViewModel.Recovery.cs` — wires the steps, reports each episode into the left panel alert stack
  (one row per episode, updated in place, log range painted), and cancels on Stop.
- Alert stack polish: a rule and a gap now separate the stack from the scene layers (they read as one
  list before), and the licence indicator uses the creator's wording — `STEAM ID NOT PRESENT` /
  `Steam ID Limit: 30fps` / `Click for More Info`, becoming `STEAM ID PRESENT` / `60fps` with a close
  control once owned.

Tests: `StreamRecoveryTests` (schedule, recover on attempt 2 with the pipe restarted each time,
complete-broadcast honesty, unknown liveness, give-up, cancel, audio-restart fault),
`FramePumpTests` now pin that process death raises `EncoderFailed` and not `Failed`.
FAST gate: 538 passed (one documented pre-existing audio failure), 0 warnings.

TASKS/task-32-stream-resilience.md

@@ -11,12 +11,18 @@ the API — creator ruling 2026-09-01): no lying in the copy.
 
 **Slices (one integration test each, in order):**
 
-1. ☐ **Blip retry** — app-side encoder restart: push dies while live (ProcessFailed / stdin
+1. ✅ **Blip retry** (shipped 2026-11-05) — app-side encoder restart: push dies while live (ProcessFailed / stdin
    backpressure death) → bounded-backoff relaunch (2s/5s/10s, N attempts) against the cached
    constant reusable-stream ingest URL. Success = push running again while the broadcast is still
    live; viewers never know. Fixes the map's stale "ffmpeg does reconnect" claim (corrected
    2026-09-01: reconnect flags are input-side only). Test: fake process fails once then starts →
    pump recovers without surfacing to the VM.
+   **Shipped:** `Services/StreamRetryPolicy.cs` (immediate, +1 s, +2 s, +3 s — minimum waits, because
+   YouTube's grace is short), `Services/StreamRecovery.cs` (the loop, with the audio pipe recreated per
+   attempt because its single-instance server is unusable after the old client died), and
+   `FramePump.EncoderFailed` separating a dead push (recoverable) from a fatal pump fault. Each episode
+   reports into the left panel's alert stack; a reconnect that lands on a **complete** broadcast is
+   reported as such instead of showing a live sign over a dead stream. Tests: `StreamRecoveryTests`.
 2. ☐ **Measured grace + the sign** — while the push is dead, escalate the existing health poll
    (30s → ~5s). ON-AIR dot goes **amber "RECONNECTING"** with a mm:ss countdown to the observed
    YouTube cutoff; the grace length is a **measured, pinned constant** — probe it on a real private