Record the Google rail's scoping and blast radius in §CO3.3

Per-client-ID app-data silo makes the rail per-site; cross-site
portability is the capsule account's job. A host's dead Google project
locks out ungraduated users in practice while every account survives on
relays -- the phrase card is load-bearing. Shared ecosystem client ID
behind a bitlogin.network relay hub considered and rejected: a chokepoint
plus federated credential readability is worse than the silo. Note the
sensitive-scope verification review hosts should expect.

Co-Authored-By: Claude Fable 5 <[email protected]>

docs/centralized-onramps.md

@@ -136,6 +136,24 @@ Password rotation while Google-managed is the graduation step (CO6 step 2):
 the Drive copy simply goes stale and dead, and the rotate screen says so
 before the user commits.
 
+**Scoping and blast radius (recorded 2026-08-04).** Drive app data is siloed
+per OAuth client ID, so the Google rail is a per-site (or per-site-family)
+convenience: a credential stored via Site A's client ID is invisible to
+Site B, whose "Continue with Google" would offer to create a NEW account.
+Cross-site portability is the underlying capsule account's job — password or
+phrase work on every BitLogin site. If a HOST'S Google project is banned or
+deleted, no Nostr account is lost (capsules live on public relays), but
+ungraduated users are locked out in practice: their credential file sits in
+their own Drive, readable only through an app bearing the dead client ID.
+Graduated users lose nothing but a button. This is why the Tier B2 phrase
+card is load-bearing, not decorative. A shared ecosystem-wide client ID
+behind a static relay hub on bitlogin.network was considered and rejected:
+it would make one domain and one Google project a chokepoint for every
+deployment, and a shared client ID lets any federated site read the user's
+credential file — worse centralization than the per-site silo it would fix.
+`drive.appdata` is a Google "sensitive" scope: hosts should expect Google's
+app-verification review before serving more than ~100 users.
+
 ## CO3.2 Architecture B — OAuth as the password manager (recommended)
 
 The insight: a BitLogin account requires a high-entropy password, but the