refactor!: drop the legacy region aliases — siteId is the only wire key

[guohai]

Summary

Follow-up to #119, per decision (no backward compatibility needed): every remaining region alias is removed from the API — siteId is now the only wire key for site values.

• Request bodies read siteId only — eval-schedules, workflow run, clash event/token/schedule. The legacy region body key is dead (400 on the missing-site path, pinned by a wire-contract test with a canonical-key control).
• Token create reads regionLocationBaseId only — drops the pre-refactor region base-id body alias.
• Clash-runner wire emits only siteId (register + assignment payloads). Verified safe: the runner daemon never read the site field at all (it consumes id/state/match.{id,topic,maxDurationSeconds} only), so no runner redeploy is required. The eval-agentd fleet is already upgraded.
• Tests: all request bodies flipped to canonical keys (~70 sites); site-id-wire.test.ts now asserts the legacy key is rejected.

Breaking change

Any external script still POSTing region (or region as a token-create base id) will get a 400. The run-your-own curl example was already updated to siteId in #119.

Test plan

• npm run check clean; unit 1557/1557; audio 12/12; E2E 133 passed / 0 failed (the previously flaky admin-login test passed in-suite this run).
• agora-e2e 13/13 and the daemon health tests re-verified after a lingering remote ConvoAI session timed out and the local eval-agent daemon was restarted — both environmental, unrelated to this change.

Generated with SMT smt@agora.build

[github-actions]

🤖 Codex Code Review

Findings

• P2 docs/openapi.yaml:1356 is now inconsistent with the enforced token-create wire key in server/routes.ts:2664. The server only reads regionLocationBaseId, but the OpenAPI schema still requires siteId and describes it as an exact allocated site id. Any client generated from the spec will send { name, siteId } and now receive 400 Name and region location required. Update the request schema/examples to require regionLocationBaseId with a base-id example like na-us-seattle.

Notes

• I did not find security, auth-bypass, injection, or performance issues in the changed route logic.
• I didn’t run the test suite; review was static due to the read-only environment.

[github-actions]

🤖 Claude Code Review

The change is mechanical and correct. I traced every consumer of the dropped keys before concluding.

Verified safe

• All client payloads already use siteId / regionLocationBaseId (client/src/pages/run-your-own.tsx:197, console-clash.tsx:183,311,370, console-eval-agents.tsx:126); nothing in client/src reads .region off an API response.
• The eval-agent daemon reads agent.siteId (vox_eval_agentd/vox-agentd.ts:336,1819) and sends no region query param.
• docs/openapi.yaml never documented region, so the dropped request alias was undocumented — narrow blast radius for scripted API users.
• Removing the aliases only narrows accepted input; no auth/authz or injection surface touched.

Deploy-ordering check (the one thing worth confirming before merge)

The removed comments at the clash-runner register/assignment responses said the alias must stay "until the next runner redeploy (vox-upgrade.sh)". I checked: vox_clash_runner/clash-runner.ts contains no region/siteId reference at all — RUNNER_REGION was removed in ebae6b4 — and it only consumes reg.id/reg.state and assignment.match.id/.topic. So in-repo runners are unaffected. This is only a hazard if runner containers older than ebae6b4 are still deployed in production. If so, redeploy runners before this merges; otherwise nothing to do.

Issues

1. tests/site-id-wire.test.ts:12-14 — stale contract comment. It still claims the clash-runner daemon wire "dual-keys siteId + region until deployed runners are upgraded — covered in clash-runner-lifecycle", which is exactly what this PR removed, and it's now directly contradicted by tests/clash-runner-lifecycle.test.ts:121 (expect(data).not.toHaveProperty('region')). Since this file's docblock is the written wire contract, leaving it inverted is worse than an ordinary stale comment.

2. tests/site-id-wire.test.ts:120 — small coverage regression. The rewrite dropped expect(created).not.toHaveProperty('region') from the create response. The response-side key assertion for /api/admin/clash-runner-tokens now exists nowhere in this file; add it back after the created.siteId check.

3. server/routes.ts:2665,2817 — const requestedLocation = regionLocationBaseId; is now a pure rename with the alias gone. Destructure as const { name, regionLocationBaseId: requestedLocation, ... } = req.body or use the name directly.

Adjacent leftover (pre-existing, not introduced here)

scripts/dev-local-run.sh:442 still does INSERT INTO eval_agent_tokens (name, region, token_hash, ...). That column is site_id since the migration (shared/schema.ts:209), so Docker-mode setup fails on this path. It also passes a macro code (na) where a full site ID is expected. Not this PR's regression, but this PR is the closing step of the migration — good place to sweep it up.

I could not run npm run check (command needed approval), so the type-check is unverified; the diff is key-level and shouldn't introduce type errors, but confirm via CI.