docs: the always-Private lock is a decision, and it unlocks at v1

Asked twice about a decision that has been settled since 2026-09-01, so this
is a documentation failure rather than a question worth answering a third
time.

The note was already there and it was accurate. It still didn't work, which is
the whole lesson: every sentence in it was descriptive. It said why the lock
exists and where the unlock lives, and not one sentence told the reader what to
DO when it looks like a defect. I read it, recognised it, and asked anyway —
because recognition is not instruction. It also pointed at TASK 36 for the
unlock while the creator's actual answer is v1, so it was confidently wrong on
top of being non-directive, which is worse than saying nothing.

Rewritten as a prohibition carrying its own trigger: verdict in imperative
voice, then the observations that make it look broken (privacy=private in the
diag line, the PRIVATE badge, recordFromStart/DVR on, no delete call in the
codebase) so recognition fires the instruction instead of prompting a question,
then the retired delete question with its verified answer.

Also: it belongs to v1, not TASK 36, and UpdateBroadcastMetadataAsync:112 is a
retrofit path, not the product change.

MyMistakes.md gets the transferable part, because the fix is not "write it
down" — it is "write decisions as prohibitions, not rationale, and treat a
repeated correction as a broken note rather than an impatient user".
TASKS.md gets it under 1.0 gates so it is a tracked deliverable, not prose.

TASKS.md

@@ -303,6 +303,16 @@ second encoder path needing a "redirect". Record+simulcast is one ffmpeg with tw
 
 ## 1.0 gates (do these before the first shipped build)
 
+- **⛔ Replace the always-Private broadcast lock with a real visibility option (creator ruling,
+  restated 2026-10-04).** `privacyStatus = "private"` hardcoded in
+  `YouTubeStreamService.CreateBroadcast` is deliberate and correct for the whole pre-v1 test
+  phase — it is the reason test VODs of a still-breaking product stay off the channel. At v1 it
+  becomes a user-selectable visibility option in the Go-Live dialog, wired to the same
+  `UpdateBroadcastMetadataAsync` path. **Before v1, do not touch it and do not raise it as a
+  question, observation or suggestion — it has been asked and answered repeatedly.** Full rationale
+  and the retired "can we delete the test VODs?" question: `ai.md` → YouTube Live API design
+  constraints.
+
 - **Kill the dev multi-instance affordance.** `Helpers/InstanceProfile.cs` is already entirely
   `#if DEBUG`, so a Release build ships as `DataRoot => DefaultRoot` / `WebViewDataFolder => null`.
   Nothing to do but *keep it that way* — and re-prove it: