feat(quality): learn the starting rate from real sessions, on the creator's permission

Each finished broadcast is filed locally — tier, probed encoder, rated, settled, steps
spent — and Models/RateHistory turns that into at most a suggestion. The app never
applies one: it asks before the next stream, "Use it" sets the rate, "Keep mine"
remembers that exact number so the same question does not return until the evidence
moves. Nothing leaves the machine.

Two rules keep it from nagging. The high-water mark is the highest rate that
*finished* a session with zero steps, not the highest seen, so one easy session (a
menu screen, a quiet game) cannot set a target the machine cannot hold. And it is
asymmetric: raising needs 10% above the current rate across five clean sessions of the
same tier and encoder, lowering needs three step-downs in five — fixing damage should
not wait for a percentage, and risking it should.

The encoder key is real, not decorative: StreamHealth.VideoEncoder is now filled from
the probe (FfmpegEncoder), so history recorded against NVENC is not applied to a
machine that later runs QSV. At startup, before anything has streamed, the last
session on that tier is the honest guess.

672 pass, 0 warnings.

docs/ai/output.md

@@ -98,6 +98,15 @@ triad is **capped VBR, not CBR**: measured 2026-11-12 on the bundled BtbN build,
 itself when `bitrate == maxrate` (`libavcodec/qsvenc.c`, `select_rc_mode`), so the triad is its whole ask;
 OpenH264's `-rc_mode bitrate` changed nothing measurable here and is not passed. YouTube's encoder spec
 requires CBR. Never assume `-maxrate` equals CBR — it does not.
+
+**The starting rate is learned, never imposed** (`Models/RateHistory`, `ViewModels/MainViewModel.Rate.cs`).
+Each finished broadcast is filed locally — tier, probed encoder, rated, settled, steps spent — and the
+only thing that may change a starting rate is a proposal the creator clicks. A **high-water mark** is the
+highest rate that *finished* a session with zero steps, never the highest number seen, so one easy session
+cannot set a target the machine cannot hold. Raising needs 10% above the current rate across five clean
+sessions of the same tier **and encoder** (history against NVENC is not evidence about QSV); lowering needs
+three step-downs in five, because fixing damage should not wait. "Keep mine" is remembered against that
+specific number, so the same question is not asked again until the evidence moves. Nothing is uploaded.
 **Record output (TASK 18):** `FfmpegArgs.Build` emits one self-contained block per output, each its own
 `-map 0:v -map 1:a` + codec tags (`AddVideoTags` helper). Stream block = `-f flv <rtmpUrl>`; record block =
 `-f mp4 <RecordPath>`. `EncoderOptions.StreamEnabled`/`RecordEnabled`/`RecordPath` gate each block, so