Demo: don't offer sign-ins that can't complete

Without a Google client id the panel now omits `googleUrl` (no dead-end 503
page), and the staff SSO button is hidden under `pnpm dev`, where no
Cloudflare Access fronts `/auth/sso` so it can only 401.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DyJyzSYpRxJuL6x6NyjpG3

Author: ryan-williams

demo/README.md

@@ -27,7 +27,7 @@ Step 5 is the load-bearing one: grant-backed sessions re-join their grant row on
 **Simulated, and labelled as such in the page:**
 
 - **Mail.** `emailCodeAuth`'s `start` reply never says whether mail went out (so the form can't probe who's allowed), and delivery *is* the verification. This demo has no sending domain for most visitors, so its `send` captures the message instead of mailing it, stashes it in a short-lived `HttpOnly` cookie only your browser can read back (`GET /auth/email/outbox`), and the form shows you the code and link. That proves nothing about the address, and the page says so. Mail really goes out only when `RESEND_API_KEY` + `MAIL_FROM` are set *and* the recipient's domain is in `MAIL_DOMAINS` — a public form that mails whatever address a stranger types is a spam cannon pointed at other people.
-- **Google.** Without `GOOGLE_CLIENT_ID` / `GOOGLE_CLIENT_SECRET`, `/auth/google/*` answers 503, One Tap doesn't render, and the page says so rather than hiding the buttons. Google exposes no API to create the client; `scripts/provision-oauth-client.mjs` walks the one manual step.
+- **Google.** Without `GOOGLE_CLIENT_ID` / `GOOGLE_CLIENT_SECRET`, `/auth/google/*` answers 503, so the page drops One Tap and the Google button (and says why) rather than offering a sign-in that can't complete. The staff SSO button is likewise hidden under `pnpm dev`, where no Cloudflare Access sits in front of `/auth/sso`. Google exposes no API to create the client; `scripts/provision-oauth-client.mjs` walks the one manual step.
 - **The directory sync.** `Admin → Allowlist → Sync now` `replaceSource`s `sync:staff@example.org` with a random subset of a five-person roster, returning the same `[{ group, source, count }]` shape `syncGroupsToAllowlist` returns. A real deployment puts that call at the marked spot in `functions/api/admin/[[path]].ts`, with a service-account key. The table isn't wired into any policy here (the demo admits any address) — which demonstrates a real property: mounting the editor never changes who gets in; `allowlistPolicy(store)` in the gate's `policy` is the separate line that does.
 
 ## Two gates, one grants table

demo/src/SignIn.tsx

@@ -34,16 +34,17 @@ export function SignIn({ onSignedIn, title }: { onSignedIn: () => void; title?:
         />
       ) : google.isSuccess ? (
         <p className="muted small inert">
-          No Google client id is configured on this deployment, so One Tap doesn't render and{' '}
-          <em>Continue with Google</em> answers 503. They're shown anyway because they're part of the panel; Google
-          offers no API to create the client, and <code>scripts/provision-oauth-client.mjs</code> walks the one
+          No Google client id is configured on this deployment, so there's no One Tap and no{' '}
+          <em>Continue with Google</em> — the panel drops a sign-in it can't complete, as any deployment should.
+          Google offers no API to create the client; <code>scripts/provision-oauth-client.mjs</code> walks the one
           manual step.
         </p>
       ) : null}
       <SignInPanel
         title={title}
-        googleUrl="/auth/google/start?next=%2Fdashboard"
-        signInUrl="/auth/sso?next=%2Fdashboard"
+        googleUrl={clientId ? '/auth/google/start?next=%2Fdashboard' : undefined}
+        // Cloudflare Access fronts `/auth/sso` only on the deployed host; in local dev it can only 401.
+        signInUrl={import.meta.env.DEV ? undefined : '/auth/sso?next=%2Fdashboard'}
         signInLabel="Sign in with SSO (staff)"
         withNext={false}
         emailAuth={{