feat(settings): editing during a session is the creator's call (default: allowed)

Creator ruling 2026-11-12: "we don't care if a creator wants to edit their scene: move stuff around,
shrink/grow a webcam view, etc. Why not?" Correct — the app was only ever *forcing* EDIT off at
go-live, never enforcing it, so the gun-safety was a habit rather than a rule.

App.LockEditWhileLive ships off: a show no longer takes EDIT away. Turning it on restores the old
behaviour exactly — go-live flips EDIT off and stop flips it back, and only because the lock took it,
so a creator who had already turned EDIT off does not get it handed back on stop.

MainViewModel.ApplyEditLockForSession holds the rule so it is testable without starting a broadcast;
EditWhileLiveTests covers both settings, the round trip, and the "don't hand it back" case. Settings →
Editing carries the checkbox.

This is the first slice of TASK 68 (editing while live).

678 pass, 0 warnings. Scope justification: Assets/starting-background.jpg is outside this unit — the
creator's replacement art, still awaiting their visual check.

docs/ai/ui-surface.md

@@ -145,6 +145,11 @@ Placement math itself is covered by `WindowPlacementTests` (pure function, no HW
   `FormattedText` — **measure, don't guess**) plus the field's padding and border. Guard:
   `ytLive.Tests/GeometryFieldWidthTests.cs`
 - Resolution tiers: 1080p60@12 (default) → 1080p30@10 → 720p60@6 → 720p30@6 → **Vertical 1080p30@10 and 1080p60@12 (9:16, 1080×1920)** — the `@` is the CBR target the encoder is asked to hold, between YouTube's H.264 recommendation and the practitioner sweet spot (its 14/17/8 recommendations are the max, the tier minimums 5/6/3 the step-down floor). Vertical mirrors its landscape pair: same pixel count, same rate. The old flat 8 Mbps was an inherited round number, not a measurement. The composition master frame is **always 1920×1080** — a tier is an output rect + target resolution over that master, so source geometry is never rewritten (no rounding drift). 16:9 tiers use the full frame; vertical tiers use a centered **607×1080** window and the preview dims the cropped side strips at 55% black with an accent outline (semi-crop — the cut area stays visible). A resolution badge in the preview corner shows the active tier. The resolution picker and live readouts (bitrate/FPS/dropped/duration) are in the top-left cell above the layers panel; the bottom bar is an empty height-preserving spacer. Under the picker sits the creator's own **rate box** (Mbps, per tier, persisted as `Video.Rate.<tier>`): the tier chooses geometry, the box chooses bits, clamped at the tier's YouTube minimum and otherwise unbounded because live step-down is the thing that catches a wrong guess. Its tooltip carries YouTube's recommendation for the tier (`Models/RateLadder`). Every consumer — encoder options, step-down policy, clip buffer — reads `MainViewModel.EffectiveQuality`, never the raw tier. A **tooltip** explains finding upload bandwidth — an in-app speed test was deliberately dropped (unreliable). The future encoder crops the master to the rect and scales to the tier's Width×Height
+- **Editing during a session is a setting (creator ruling 2026-11-12).** `App.LockEditWhileLive` is off
+  by default: a show does not take EDIT away, so a creator may move a layer or resize a webcam while
+  live. On restores the old gun-safety — go-live flips EDIT off, stop flips it back, and only because
+  the lock took it away (`MainViewModel.ApplyEditLockForSession`, `EditWhileLiveTests`). Settings →
+  Editing carries the checkbox.
 - **OPEN (creator, 2026-11-12): can a locked scene still be changed through a layer's visibility eye?**
   Reported as "the creator can still use the layer icon — visibility — if it was already enabled for
   that layer". Not reproduced from the obvious paths: with EDIT off the left panel swaps the layer list