[JeongCheolLee]

Problem

The services already read their limits from the environment (api/src/config.ts, service/src/config.ts), but docker-compose.yaml does not let .env reach them:

• sandbox-runner hard-codes SANDBOX_OUTPUT_MAX_SIZE=65536, SANDBOX_RUN_TIMEOUT=300000 and SANDBOX_RUN_CPU_TIME=300000, so the same keys in .env are ignored.
• JOB_TIMEOUT and MAX_FILE_SIZE are not passed to api, service-worker or egress_gateway at all. Uploads over 25 MiB are rejected with 413 by the upload route and the only way to raise the cap is a Compose override file.
• .env.example lists SANDBOX_RUN_TIMEOUT=15000 and SANDBOX_RUN_CPU_TIME=10000, which suggests they apply although they never did.

Change

• Interpolate the five variables with today's values as defaults: SANDBOX_RUN_TIMEOUT / SANDBOX_RUN_CPU_TIME = 300000, SANDBOX_OUTPUT_MAX_SIZE = 65536, JOB_TIMEOUT = 300000 (api, service-worker, egress_gateway — the gateway derives the egress grant TTL from it), MAX_FILE_SIZE = 26214400 (api, the upload route's busboy limit).
• .env.example: replace the two inert values with commented defaults plus a short explanation.
• README (Local Development): one paragraph listing the variables and defaults.
• tests/compose-bridge-config.cjs: assert the rendered defaults and that overrides reach each service.

Compatibility

With no new keys in .env, docker compose config renders exactly the previous values.

Upgrade note: an existing .env copied from the old .env.example still contains SANDBOX_RUN_TIMEOUT=15000 and SANDBOX_RUN_CPU_TIME=10000. Those values will now take effect (15 s / 10 s instead of 300 s). Happy to name this in release notes, or drop the two runner timeouts from this PR (a small amend touching only those lines and their test entries) if you prefer.

Testing

• node tests/compose-bridge-config.cjs → "Compose bridge configuration passed (pairing, opt-in recovery, durable Redis, execution limits)"; with the Compose change reverted, the new assertions fail (api JOB_TIMEOUT).
• git diff --check clean.
• bun run test in api/ was not run on this branch (no TypeScript changed). For reference, on main on a macOS host it gives 504 pass / 3 skip / 14 fail; the 14 are environment-dependent (scripts using GNU ln -sfnT, plus 4 hardened-startup config tests), not related to this change.
• Not run: a full stack boot.
• Production use: the same pass-through (with larger values: 100 MiB uploads, 300 s runs) has been running in a downstream deployment since mid-October; 30/60/99 MiB uploads succeeded and 110 MiB returned 413.

Checklist

• Defaults unchanged
• Docs and .env.example updated
• Test added
• Helm: already exposes these through values; no change