feat(33): shed our own capture cost first; the task is done

Last slice. 590 green, 0 warnings.

- **Shed before you charge the viewer.** On machine evidence the policy's first act is
  `ShedCaptureCadence`: `ScreenCaptureFrameSource` widens its conversion interval 10 ms → 33 ms (≈100
  → 30 conversions/s) through a new `ScreenCaptureManager.ShedLoad`. The output tier, the declared fps
  and the viewer's picture are untouched — we stop paying for readbacks we were throwing away. It
  costs no step budget; if the starvation persists, the fps ladder runs on the next clean window.
- The shed is reset on every stop path, so a cheap session cannot leave a later one capped.
- **The session line is a Logs-tab line, not a session-report line.** The session report is the money
  summary (Super Chats, per currency); quality chatter there would bury the numbers it exists for. The
  cause-tagged line already lands in the log at the moment of the step.

TASK 33 is complete: two ladders, budgets, floors, ambiguity, one-way with recovery behind a flag, the
relaunch, the copy, and the cost shed. 18 tests pin the ladders, the copy and the restart.

TASKS/task-33-bandwidth-step-down.md

@@ -21,10 +21,14 @@ that step relieves nothing. Fps is **not** a congestion lever: same bitrate, sam
 
 ## Shed our own load before asking the viewer to pay
 
-1. If our capture/convert cadence is what starves, **halve our own capture rate first** — same output
-   tier, less of the creator's machine. This is the "budget streamer self-streaming gameplay" case.
+1. If our capture/convert cadence is what starves, **halve our own capture rate first**
+   (`ScreenCaptureFrameSource.ShedLoad`, 10 ms → 33 ms between conversions) — same output tier, less of
+   the creator's machine. It costs no step and changes nothing the viewer sees.
 2. Only then step fps, then resolution.
 
+**Shipped 2026-11-09** — `StepDownPolicy` + `StepDownPlanner` + `FramePump.ChangeEncoderAsync` +
+`MainViewModel.StepDown`, 18 tests. The shed runs on machine evidence before the budget is touched.
+
 ## Budgets, floors, terminal state
 
 | Start | Steps allowed | Worst case it can reach |
@@ -49,8 +53,9 @@ caused it, and what the app already did** — no exception text, no error codes:
 - theirs: *"Your upload couldn't hold 8 Mbps, so LlamaCasty dropped it to 6.4 to stop the freezing.
   It will stay there for this stream."*
 
-One toast per step, plus one session-report line (`quality stepped down 12:04 — encoder` / `—
-upload`) so support answers from data, not memory. Wording rules live in
+One toast per step, plus one **Logs-tab** line (`quality stepped down 12:04 — encoder` / `— upload`,
+cause-tagged) so support answers from data, not memory. It is logged rather than added to the session
+report on purpose: that report is the money summary, and quality chatter in it would bury the numbers. Wording rules live in
 [`docs/ai/ui-surface.md`](../docs/ai/ui-surface.md) → Toast notifications.
 
 ## Tests