docs: Go Live IS private (verified), and v1 is where that guarantee ends

The creator's standing doubt: "I wasn't sure that the go live video would be
private." Answered by tracing every path that can touch privacy, not by
reassuring:

  CreateBroadcast          -> privacyStatus = "private"   hardcoded
  GoLiveViewModel          -> Visibility => "Private"     hardcoded
  BeginTestStream          -> StreamVisibility = "Private" hardcoded
  UpdateBroadcast          -> the only code that can change it — NO CALLER

UpdateBroadcast's sole caller in the repo is BroadcastPullOutTests.cs:120. It
is dead code. So there is no path today by which a broadcast this app creates
becomes non-private, and the "do not populate my channel with videos showing
the app at its worst" concern is fully met. Verified, not assumed.

Which makes the safety accidental rather than structural, and that is the part
worth writing down. LiveBroadcastFormViewModel still offers
VisibilityOptions {private, unlisted, public}, and UpdateBroadcast would honour
it. So the v1 visibility option is precisely the change that first wires that
method up — v1 is the moment private stops being guaranteed and becomes a
user-selectable default. Intended at v1, ruinous before, and "it's dead code,
let me call it" is not a valid reason to do it early.

Also recorded, having been absent from the map entirely: the TEST button is
hidden at v1. Its real job is being the guaranteed-private path (hence the
hardcoded Private at BeginTestStream:105), which the existing "dry-run"
comment on ShowTestButton does not capture — that framing is now known to be
incomplete, and must not be used to re-derive why the button persists.

Corrects a fact I got wrong one commit ago: the method is UpdateBroadcast, not
"UpdateBroadcastMetadataAsync", and I described it as an available retrofit
path when it is in fact unreachable in production.

Open, deliberately, for v1 rather than now: whether a dry run is still wanted
on its own merits once Test is hidden.

TASKS.md

@@ -307,11 +307,26 @@ second encoder path needing a "redirect". Record+simulcast is one ffmpeg with tw
   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
+  becomes a user-selectable visibility option in the Go-Live dialog. **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.
+  - **Verified 2026-10-04: a Go Live video IS private.** Three independent hardcodes
+    (`CreateBroadcast` → `"private"`, `GoLiveViewModel.Visibility => "Private"`,
+    `BeginTestStream` → `StreamVisibility = "Private"`) and the one method that could change it,
+    `YouTubeStreamService.UpdateBroadcast`, has **no production caller** — only
+    `BroadcastPullOutTests.cs:120`. No path exists today by which an app-created broadcast becomes
+    non-private.
+  - **Two coupled v1 items — both are the deliberate end of that guarantee:**
+    1. **Hide the TEST button.** It exists as the guaranteed-private path; once visibility is
+       selectable, a separate safe button is redundant. One-line change —
+       `ShowTestButton => ShowStreamActions && IsConnected` is a computed predicate, not a setting.
+    2. **This is the unit that first wires `UpdateBroadcast` into production.** It is the only code
+       that can change a broadcast's privacy, and it is currently dead. Wiring it is exactly when
+       private stops being guaranteed and becomes a user-selectable default. Correct at v1,
+       ruinous before — and "it's dead code, let me call it" is not a reason to do it early.
+  - A **dry run** may still be worth having at v1 on its own merits; that is a separate question
+    from the privacy mechanism and is **not** decided by the above.
 
 - **Kill the dev multi-instance affordance.** `Helpers/InstanceProfile.cs` is already entirely
   `#if DEBUG`, so a Release build ships as `DataRoot => DefaultRoot` / `WebViewDataFolder => null`.