Plan String ID rollout for hosts with unmanaged Google accounts #70

Follow-up to #68 (String ID host auth), from cross-checking it against String ID's Google sign-in in ghostleek/string-id#77.

Context

Today Bingo accepts any Google account through Google's in-page sign-in button. It doesn't check email_verified or hd (the Google Workspace domain), and it keys users by email.

String ID only creates an account from Google, or matches one by email, when Google vouches for the address: a Gmail/Googlemail address, or hd present. Any other Google account gets email_proof_required. An example is a Google account registered with a Yahoo or school address that isn't on Google Workspace.

Effect on existing Bingo hosts

A host who created games with such an account signs into String ID and sees "Please sign in by email first, then connect Google from your profile." Once they do that, #68's bridge (users.google_id = String ID googleAccountId) finds their games as intended. Nothing is lost, but there is an extra step, and the host will only take it if they know why.

To do before enabling String ID sign-in

• Add a rollout note to Add String ID host auth and guided game creation #68's spec or README and to host-facing comms: unmanaged Google accounts must sign in by email first, then use Profile → Connect Google.
• Count the affected hosts: users rows whose email isn't @gmail.com/@googlemail.com. (hd was never stored, so Workspace hosts can't be separated from unmanaged accounts by query alone. Treat the count as an upper bound.)
• During the pilot, confirm that one existing host's legacy google_id equals the googleAccountId String ID returns. Google documents sub as the same for an account across OAuth clients, so the bridge should work even though Bingo and String ID use different client IDs. This hasn't been tested end to end.

Deploy order is unchanged: string-id #75, then db:push for google_account_id, then string-id #77, then this repo's #68.