[jm-rivera]

The client contract's served document and recordings date from dfo-apis 635943e0, before DevelopmentFinanceObservatory/apis#37 made the Datasets versions page carry a required enrichment_stamp. DevelopmentFinanceObservatory/apis#72's exchange gate therefore refuses the recorded fetch-ref-newest-version versions response. The validator ties every recorded scenario to the served document's commit, so this PR captures the whole contract again at dfo-apis 035d29cd0: served/openapi.json and served/SOURCE.json through tools/capture_client_contract.py openapi, all 31 recorded scenarios against the deployed dev app in one run, and the 87 synthetic scenarios derived from them. The scenarios hold 13,080,568 bytes, 1,124,502 of them in binary bodies, against 13,911,513 at 95a15cf. The validator and the record run now refuse a scenarios/ directory over 16,000,000 bytes (SCENARIOS_BUDGET), and the validator tests hard-link their package copy rather than copying 14 MB per test.

"Newest version" now means the first listed version whose base_content_version is null, read across every page of the versions list (validate_client_contract.newest_plain, versions_path with ?limit=100 and the cursor). On dev a derived groupby version of spec_774d6c001a6250aa67ca676ab067895e is listed ahead of its plain build, and the old first-entry rule handed a client that rendering as the newest data. fetch-ref-newest-version now requires a derived version listed first, so the record shows the rule skipping it. A version without a string-or-null base_content_version, or a next_cursor of another type, refuses contract_violation. The README and scenario.schema.json state the rule.

Twelve scenario questions are reworded where Search at 035d29cd0 answers the old wording with another shape. GNI of Germany now answers definite, so the candidates scenarios ask about mortality in Kenya from 2013 to 2022. "Debt of Kenya" refuses no_observations with no options, so choose-option-beside-definite asks "GDP of the G20 in 2015, and Germany India ODA". The DAC2a every-provider build estimates 1,632 rows now that an unnamed donor side reads its published total, so the async scenarios ask for ODA disbursements from the DAC (or OECD) countries to the G77 countries over six decades, about 110,000 rows of one variable, whose finished manifest stays small. The place question adds "in 2018", because dev's response cache holds a definite answer for the bare wording. Fresh runs of the bare wording still refuse entity_ambiguous. Each new wording gave its shape on every fresh probe of its template.

Each ref record that holds members now names the scenario serving them, and the validator checks every member's spec, content version, sentence and digest against that scenario (_served_by). Ten refs carried the digest of a Parquet body the re-record replaced, and ref-frame-layout pinned the long file's digest under a frame rendering; both now match what their scenarios serve.

Testing: uv run tools/validate_client_contract.py reports a valid contract with 118 scenarios, tools/tests gives 517 passed, including new parametrised cases for the newest-plain rule, an unreadable versions page, the size budget and four stale-ref contracts, and python/client-contract gives 78 passed with ruff and ty clean. Against this tree, DevelopmentFinanceObservatory/apis#72's tests/contract gives 102 passed.