max_wait_seconds default exceeds the 30s proxy-safety ceiling it documents

GET /jobs/{id}?wait=N holds a request open for up to N seconds, capped server-side at max_wait_seconds so a long-poll response can never still be pending when a load balancer or reverse proxy decides the connection is dead and kills it. The comment above this field names GCP's 30-second backend timeout as the shortest common default the cap has to respect -- but the value itself has been bumped past 30. The first client sitting behind infrastructure with a 30s timeout whose long-poll request lands near the new, larger ceiling sees their connection killed by the proxy while the app still thinks it's legitimately waiting -- a request that should return a clean response instead just dies with a connection reset, with nothing in this service's own logs pointing at the real cause.

Settings.max_wait_seconds defaults to 45.0, but the comment directly above the field says it "must never exceed 30s, the shortest of the timeouts above -- going past it defeats the entire point of capping wait at all."

1. python3 -c "from app.config import Settings; print(Settings().max_wait_seconds)" -- prints 45.0, compare against the "must never exceed 30s" comment directly above the field in app/config.py.

Same failure mode as most config-drift bugs: nothing in the type system, a linter, or a code-review skim catches "this number no longer satisfies the sentence written directly above it" -- a comment and a value are only connected by convention, not by anything the language enforces. The only thing that catches it is careful review or a test that encodes the promise numerically instead of leaving it as prose.

Re-read the comment block above max_wait_seconds in app/config.py, specifically the "must never exceed 30s" sentence, and pick a value that actually satisfies it.