[jm-rivera]

The client contract described the website proxy's own refusals as a second body shape, {error, retry, detail} with the code in error, beside the problem documents every other refusal sends, and its served OpenAPI predated the timed_out no-data reason that apis already emits, so neither client could name it.

The proxy's rate_limited (429, with Retry-After) and transient_unavailable (502) refusals are now application/problem+json documents with type, title, status, detail, code, retryable: true and trace_id. python/client-contract/README.md, proxy-codes.json, client-codes.json and scenario.schema.json describe one refusal shape. tools/validate_client_contract.py reads the code and retryable from the problem document only, and a new _check_proxy_problem refuses a proxy code sent as plain JSON, without a common member, or not retryable. tools/capture_client_contract.py writes the website's document, and search-proxy-rate-limited and search-proxy-unavailable are re-derived. The website side is in DevelopmentFinanceObservatory/website (proxy problem documents, linked once open).

The README states that a 202 operation reads pending or running, or failed for a deterministic failure, and never done; _check_accepted refuses a scenario whose 202 reads done. fetch-spec-accepted-running pins a 202 that reads running, and fetch-spec-poll-pacing-changes pins a retry_after_ms that changes from poll to poll (2500, 4000, 1000 ms), which the live re-record had stopped exercising. The apis change that resets a done operation on submission ships in the companion apis PR; dev answers pending for every recorded 202 already.

served/openapi.json and SOURCE.json are re-captured from apis 0ba344270, which adds timed_out to NoData.reason and an optional entity_refs on four answer-part schemas, and the 31 recorded scenarios are re-recorded live against dev at that commit, so every origin.dfo_commit matches. Also: a wrapped docstring line in the validator, and the test id action-row-no-data-reason-missing.

A reviewer should check _check_proxy_problem, _check_accepted, and that the re-recorded scenarios still pin what their names say.

Testing: uv run tools/validate_client_contract.py reports the contract valid with 120 scenarios; tools/tests passed (525) and python/client-contract passed (78), with ruff check and format clean on the touched files. The new test rows for a proxy problem without retryable, a proxy problem in plain JSON and a 202 reading done fail with their checks removed.