Add the Stage 5 Cloud Run Simulation Entry service

[anth-volk]

Summary

• add the separate authenticated policyengine-simulation-entry FastAPI service on Cloud Run;
• preserve the existing Modal gateway contract and pass job IDs through unchanged;
• add caller/backend M2M authentication, startup and recursion guards, backend attribution, and structured observability;
• replace opaque dict/dict[str, Any] boundaries with named Pydantic, root-model, and TypedDict schemas;
• publish the complete single-year macro result, policy-change, version, health, readiness, auth-token, and telemetry shapes through the shared contract/OpenAPI;
• add a GitHub deployment workflow for no-traffic candidates while keeping one-time infrastructure setup manual and outside committed automation;
• keep all Cloud Run traffic changes in explicit operator-run commands;
• add separate deployed authentication jobs for staging and production;
• generate and publish the simulation SDK from the exact successfully qualified deployment SHA.

Why

Stage 5 establishes the permanent simulation control-plane boundary before later stages migrate routing, durable state, and worker responsibilities. The existing Modal gateway remains the authenticated backend and rollback target during this stage.

The explicit shared schemas make the entrypoint, existing gateway, executor, OpenAPI artifact, and generated SDK agree on the same wire contract instead of accepting or advertising arbitrary objects.

Impact

The new service can be deployed and qualified independently without changing production traffic. Existing clients retain the same request/response shapes and job identifiers. The old Modal deployment remains intact.

One-time cloud projects, identities, IAM, workload identity, and secret resources are configured manually by authorized operators using private runbooks. The public deployment guide describes only the architecture and lifecycle. Credential values remain in the cloud secret store; the workflow receives only environment-owned resource references.

Root causes addressed

The initial implementation also needed tighter WIF trust, a valid-length GCP project ID, robust outbound 401/403 credential refresh, stronger recursion validation, correct generated-client checkout provenance, an explicit Modal runtime extra, corrected FastAPI handler typing, explicit schemas at every newly introduced mapping boundary, and removal of inappropriate committed one-time infrastructure automation.

Validation

• Simulation Entry: 52 tests passed; Ruff and Pyright clean.
• Shared simulation contract: 59 tests passed; Pyright clean.
• Existing Modal gateway: 101 tests passed.
• Executor schema/output/standalone-contract tests: 41 passed; changed modules pass Pyright.
• Three separate deployed-authentication tests collect.
• All nine simulation integration tests collect against the regenerated typed SDK.
• OpenAPI and the generated Python client contain concrete macro-result, labor-supply, geography, policy-change, version, health, and readiness models.
• The production container builds with a Modal-free 53-package environment.
• Domain and manual-traffic scripts pass syntax and dry-run checks; no one-time infrastructure bootstrap is committed.

Live authenticated tests require deployed candidate URLs and environment secrets and run in the new CI/CD jobs.

Fixes #650