Ship the Google credential with the Worker version, not the GitHub one

The production deploy was still writing GITHUB_OAUTH_CLIENT_ID and
GITHUB_OAUTH_CLIENT_SECRET onto a Worker that no longer has a GitHub
provider, and refusing to deploy at all if either Actions secret was
absent. Two dead secrets refreshed on every deploy, and a hostage: deleting
the stale Actions secrets would have broken deploys.

The design is kept because the design is right — credentials ride with the
Worker version, so a version is self-contained and a deploy re-establishes
sign-in rather than depending on someone having run `wrangler secret put`
once. Only the destination changes: the same two Actions secrets now land
on GOOGLE_OAUTH_CLIENT_ID and GOOGLE_OAUTH_CLIENT_SECRET.

The config guard asserted that the deploy sources the pair from the
production environment, and it kept passing all day while the pair went to
the wrong bindings — because what went stale was the destination and the
guard only watched the source. It now asserts the binding names, and that
no GitHub OAuth binding is uploaded at all. Revert-checked: putting the
GitHub names back fails with the message that names the consequence.

DEPLOY ORDER MATTERS HERE. The two Actions secrets still hold the GitHub
client ID and secret. Pushing this before they are updated to the Google
values would overwrite the working GOOGLE_* secrets with GitHub ones and
break sign-in on the live site immediately. This commit is deliberately not
pushed.

Local proof: `npm run build` end to end, 81 config assertions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: sametbasbug

.github/workflows/deploy-production.yml

@@ -256,7 +256,7 @@ jobs:
           ORBIT_MCP_DELEGATION_PEPPER_V1: ${{ secrets.ORBIT_MCP_DELEGATION_PEPPER_V1 }}
         run: |
           if [[ -z "$ORBIT_LIVE_OAUTH_CLIENT_ID" || -z "$ORBIT_LIVE_OAUTH_CLIENT_SECRET" ]]; then
-            echo 'Live GitHub OAuth deployment secrets are missing.' >&2
+            echo 'Live Google OAuth deployment secrets are missing.' >&2
             exit 1
           fi
           if [[ -z "$ORBIT_MCP_SERVICE_SECRET_V1" || -z "$ORBIT_MCP_DELEGATION_PEPPER_V1" ]]; then
@@ -268,8 +268,8 @@ jobs:
           trap 'rm -f "$oauth_secrets_file"' EXIT
           chmod 600 "$oauth_secrets_file"
           jq -n '{
-            GITHUB_OAUTH_CLIENT_ID: env.ORBIT_LIVE_OAUTH_CLIENT_ID,
-            GITHUB_OAUTH_CLIENT_SECRET: env.ORBIT_LIVE_OAUTH_CLIENT_SECRET,
+            GOOGLE_OAUTH_CLIENT_ID: env.ORBIT_LIVE_OAUTH_CLIENT_ID,
+            GOOGLE_OAUTH_CLIENT_SECRET: env.ORBIT_LIVE_OAUTH_CLIENT_SECRET,
             ORBIT_MCP_SERVICE_SECRET_V1: env.ORBIT_MCP_SERVICE_SECRET_V1,
             ORBIT_MCP_DELEGATION_PEPPER_V1: env.ORBIT_MCP_DELEGATION_PEPPER_V1
           }' > "$oauth_secrets_file"

docs/V6_PROJECT_LEDGER.md

@@ -2056,3 +2056,16 @@ Anything under `docs/archive/` describes an earlier state and is frozen. Read it
   rewritten owner test and would otherwise have vanished with it.
 - Local proof: `npm run check` 0 errors 0 hints, `npm run build` end to end —
   227 D1 tests, 2791 site assertions, 557 browser assertions.
+- Two things surfaced only after the removal deployed. Migrations are applied
+  by the deploy workflow itself, not by hand — 0040 landed at 13:40:13 as part
+  of run 31393933857, and the "new schema, old code" window earlier in the day
+  had been self-inflicted by applying 0039 manually three minutes ahead of the
+  push. And the deploy was still uploading `GITHUB_OAUTH_CLIENT_ID` and
+  `GITHUB_OAUTH_CLIENT_SECRET` onto a Worker with no GitHub provider, failing
+  the deploy if either was absent. The workflow now uploads the Google pair
+  from the same two Actions secrets, and the config guard asserts the binding
+  names rather than only the Actions ones — the old assertions passed
+  throughout, because what went stale was the destination, not the source.
+- `production:config:check` moved into `npm run build`. It had drifted twice
+  in one day and both times the drift was invisible locally, because the guard
+  only ever ran in CI.

scripts/orbit-production-config-tests.mjs

@@ -291,6 +291,21 @@ assert(
   deployWorkflow.includes('--secrets-file "$oauth_secrets_file"'),
   'production deploy does not upload the live OAuth pair with the Worker version',
 );
+/* Hangi BAĞLAMAYA yazdığı da kilitli, yalnız Actions sırrının varlığı değil.
+ * Sessizce eskiyen tam olarak buydu: sağlayıcı Google'a geçtikten sonra iş
+ * akışı `GITHUB_OAUTH_*` yazmaya devam etti, iki ölü sır her dağıtımda
+ * tazelendi ve hiçbir kontrol bunu görmedi — çünkü kontroller Actions
+ * tarafındaki adlara bakıyordu ve o adlar değişmemişti. */
+for (const binding of ['GOOGLE_OAUTH_CLIENT_ID', 'GOOGLE_OAUTH_CLIENT_SECRET']) {
+  assert(
+    deployWorkflow.includes(`${binding}: env.ORBIT_LIVE_OAUTH_CLIENT_`),
+    `production deploy does not upload ${binding}; the Worker version would ship without a usable sign-in credential`,
+  );
+}
+assert(
+  !/GITHUB_OAUTH_CLIENT_(?:ID|SECRET):\s*env\./u.test(deployWorkflow),
+  'production deploy still uploads GitHub OAuth secrets to a Worker that has no GitHub provider',
+);
 assert(
   deployWorkflow.includes("trap 'rm -f \"$oauth_secrets_file\"' EXIT"),
   'production deploy does not clean up its temporary OAuth secrets file',