fix(GAT-9016): allowlist the deployed origins for UI actions

[calmacx]

Written with Claude Code.

What

Adds allowedActionOrigins to react-router.config.ts: the prod custom domain, plus a *.europe-west1.run.app wildcard covering the Cloud Run URLs for dev, preprod and prod.

Why

Every POST to a UI route has 400'd on Cloud Run since the react-router 7.16.0 → 7.18.4 bump in #167 — Deep Refresh, Sync New, Cancel, per-row refresh and the whole benchmark page fail with "Unexpected Server Error". The JSON API is unaffected, because the guard only runs on single-fetch .data submissions.

The guard tightened in 7.18.3. Up to 7.18.2 it compared the Origin header's host against the host of the request, which is scheme-insensitive and so blind to a TLS-terminating proxy. From 7.18.3 it compares the full origin: originUrl.origin === requestUrl.origin. Cloud Run terminates TLS at the front end, so the container sees plain HTTP; react-router-serve never sets express's trust proxy, so req.protocol is http and @react-router/express builds request.url as http://<host>/results.data while the browser sends Origin: https://<host>. The schemes differ, the guard throws, and singleFetchAction returns a bare 400 — the Error: Bad Request at singleFetchAction (chunk-H4DAEOV7.mjs:867) in the dev logs.

allowedActionOrigins is matched on host alone, so listing the deployed origins clears the scheme mismatch without changing how the service is served. Upstream has declined to fix the proxy case (#15454, #15474), so this is the supported route rather than a stopgap.

Testing

npm run lint, npm run typecheck and npm run test:unit (28 passed) are clean, and the full integration suite passes against a production build — 13 files, 90 tests.

The guard was then exercised directly with POST /results.data against that build, varying only the Origin header. The prod custom domain and the dev, preprod and prod Cloud Run hosts all return 200, including the exact dev host from the failing logs; a same-origin local http submission still returns 200; https://evil.example.com returns 400.

Notes

• The wildcard is deliberately broader than our own services. Matching is whole-segment — * covers exactly one segment and ** only leading segments — so no pattern can anchor on the hdr-gateway-traser- prefix, and any pattern matching our hosts also matches every other tenant's Cloud Run service in the region. Accepted in exchange for a list that needs no edit when an environment or project number changes.
• This drops the older -ew.a.run.app Cloud Run URLs, which the wildcard does not span. They still resolve, and gateway-api still calls TRASER through one via TRASER_SERVICE_URL, but those are resource-route requests that the guard does not apply to. Only a human browsing the admin UI at a legacy URL would see a 400.
• The value is baked in at build time and cannot come from the runtime environment: the vite plugin serialises it into build/server/index.js, and the guard reads it off the build module's namespace object. Runtime configuration would need a custom server wrapping the build — the approach prototyped in fix(GAT-9016): serve behind a TLS-terminating proxy #169 and rejected.
• Supersedes fix(GAT-9016): serve behind a TLS-terminating proxy #169, which replaced react-router-serve with a custom express server setting trust proxy. That fixes request.url globally rather than just the guard, but it was more surface area than the problem warrants.

[gh-actions-pipelines-app]

🎉 Great job! Your PR title follows the correct format. 🚀