docs: OAuth verification is PARKED, not the next step — the map was lying

The 2026-09-27 entry sat under a "NEXT STEP" heading and framed the Google
verification as the top priority. It was neither un-attempted nor un-blocked:
the attempt had already failed on a Google-side bug and the creator had
already ruled it unimportant for where we sit. A "next step" heading lends a
dead end borrowed authority, and the next session would have opened the
console instead of the editor.

Records the ruling in the terms that change behaviour: attempted, died on
Google's side, ruled unimportant, do not re-attempt. States the cost of
tabling it honestly — an accepted 7-day refresh-token expiry while the
consent screen sits in Testing, which is why the creator kept having to
re-consent. The sensitive-vs-restricted classification was never read and is
moot until a second real user or Store submission.

The mechanism of the Google-side bug was never recorded and is left
deliberately blank rather than reconstructed — a confident fiction in a
memory map is the one sentence the next session would trust. The project
number and console link stay in ai.md:233; they cost a hunt and are still true.

The two code scope cleanups survive the tabling (neither needs verification
to land): drop the redundant force-ssl scope, and move the uploads-playlist
fetch off the user's session token. The channels?mine=true call on the same
service legitimately needs the session — flagged so it is not "fixed" later.

No code touched. Test state unchanged.

HANDOFF.md

@@ -36,32 +36,40 @@ browser. **Coverage gap:** the *ordering* fix (defect 1) has no automated test
 hardcoded in `MainViewModel` and `ChangeAccountAsync` is private, so a real test would shell out to
 the browser. Wiring an auth seam into `MainViewModel` is a deliberate follow-up, not a bug-fix extra.
 
-## ⏭ NEXT STEP (2026-09-27) — Google OAuth verification: open blocker, nothing recorded before
+## 🗄 PARKED — Google OAuth verification: attempted, hit a Google-side bug, tabled by ruling
+
+**Creator ruling: unimportant for where we currently sit.** Verification is *not* a live blocker and
+**must not be re-attempted, re-derived, or re-researched** without a new ruling. The 2026-09-27 entry
+that preceded this one wrongly sat at `⏭ NEXT STEP` and framed it as the top priority — that was the
+plan going in, not the outcome, and the outcome was never written down. Corrected 2026-09-28.
+
+**What happened:** the verification attempt was made and failed on a bug **on Google's side** — not
+something we can fix, work around, or retry our way past. ⛔ **The exact mechanism was never recorded
+and is deliberately left blank** rather than reconstructed from memory: a confidently wrong note here
+is worse than none, because the next session would trust it. Do not go looking for the cause.
 
 **Owning account (creator-confirmed): `llamachile.shop@gmail.com` ("gramps").** Cloud project number
-`198374416003` (from the ClientId). Open `https://console.cloud.google.com/apis/credentials?project=198374416003`
-signed in as that account. Note the project picker defaults to the **"Recent"** tab — switch to
-**"All"**. ⛔ Do not confuse this account with the YouTube channel account used in the app.
+`198374416003` (from the ClientId) — banked in `ai.md:233`, **do not re-hunt it.** The one-hop console
+link is `https://console.cloud.google.com/apis/credentials?project=198374416003` (picker defaults to
+**"Recent"** — switch to **"All"**). ⛔ Not the same account as the YouTube channel signed into the app.
 
-**Answer these two, and the whole verification path is known:**
-1. OAuth consent screen **Publishing Status** — "Testing" or "In production"? If still *Testing*:
-   **100 test-user cap and refresh tokens expire every 7 days**, which is exactly why the creator kept
-   having to re-consent. Both limits vanish on going to production.
-2. Is `https://www.googleapis.com/auth/youtube` flagged **sensitive** or **restricted**? Sensitive →
-   Google review only (free, self-service, weeks). Restricted → adds an **annual CASA security
-   assessment by a Google-approved third party** (real cost, recurring, "several weeks" per Google).
-   Google publishes the scope list but **deliberately does not publish this classification** — the
-   indicator lives only in the console, so it cannot be researched, only looked up.
+**What tabling costs, stated honestly:** if the consent screen is still in **Testing**, the 100-user
+cap and the **7-day refresh-token expiry** both stand — that expiry is why the creator kept having to
+re-consent. Parking verification does not fix that; it accepts it for the solo-use phase. It becomes
+real work the moment a *second real user* needs to sign in, or at Store submission (TASK 48). The
+sensitive-vs-restricted classification was never read and is moot until then.
 
-**Scope cleanups found (2026-09-27, not yet done — both trivial, both reduce verification surface):**
+**These two survive the tabling** — neither needs verification to land, and both shrink the surface
+if it ever comes back:
 - `Services/YouTubeAuthService.cs:18` requests `auth/youtube` **+ `auth/youtube.force-ssl`**.
   `force-ssl` is **redundant** — Google's liveChat docs list `auth/youtube` as an acceptable
   alternative, and it is the broader of the two ("Manage your YouTube account" ⊃ "see/edit/delete
   your videos, ratings, comments, captions"). Drop it: one fewer scope to justify, one fewer consent line.
-- `Services/ChannelStatsService.cs:107` calls `playlistItems.list` on the creator's own uploads
-  playlist (`UU…`) — **public data, needs no OAuth scope at all** (API key suffices). It currently
+- `Services/ChannelStatsService.cs:104,107` — `playlistItems.list` on the creator's own uploads
+  playlist (`UU…`) is **public data needing no OAuth scope at all** (API key suffices); it currently
   rides on the user's session token. Does not change the requested scope (`auth/youtube` is forced by
   `liveBroadcasts.*`/`liveStreams.list` regardless) but that fetch should not need user credentials.
+  The `channels?mine=true` call on the same service **does** need the session — do not "fix" it.
 - `auth/youtube` is **unavoidable**: no narrower scope covers live broadcast create/transition.
 
 ## ✅ DECIDED 2026-09-27 — pricing: `$10/mo` subscription, or `$400` lifetime, **no annual**