Fix simulation request correlation and service metadata

[anth-volk]

Fixes #658

Summary

• standardize simulation HTTP correlation on X-PolicyEngine-Request-Id
• preserve supplied or generated IDs through the Cloud Run Entrypoint and Modal gateway
• give the Entrypoint, gateway, and executor explicit FastAPI service identities
• recognize APP_ENVIRONMENT without changing the existing environment precedence
• document the three-service observability boundary

Root cause

The Entrypoint forwarded X-Request-ID, but policyengine-observability reads X-PolicyEngine-Request-Id, so the Modal gateway generated a different UUID. The shared FastAPI initializer also hard-coded the executor service name and did not consider the Cloud Run APP_ENVIRONMENT value.

Impact

Entrypoint and gateway logs can now correlate a synchronous request with the same ID. Structured records identify the correct service and deployed Entrypoint environment. Authentication, routing, secrets, workflows, API schemas, generated clients, and asynchronous job semantics are unchanged.

Tests

• test-first regression commit captured the expected pre-fix failures
• simulation observability: 28 passed
• simulation entry: 64 passed
• simulation gateway: 103 passed, 1 deployment integration test deselected
• simulation executor: 391 passed, 2 deployment integration tests deselected
• Ruff CI formatting lane: 62 source files formatted
• targeted Pyright: zero errors for every modified source file
• Entrypoint Docker image build: passed
• git diff --check: passed

Real Modal integration smoke tests were not run because they create ephemeral deployments; the hermetic Modal image-definition and import-smoke tests passed in the gateway and executor unit suites.