Cover relationships(type, source) on entities

[makegov-mark]

What

Covers the two new keys on the entity relationships expand introduced in Tango API 4.20.0: type (the stable relationship-type code) and source (where the tie came from). Both are shape-selectable, so shape="uei,relationships(type,source,uei)" now resolves against the SDK's schema.

Why

The SDK's vendored contract predated the API change, so RELATIONSHIPS_SCHEMA described the expand as display_name / relation / uei only. Left alone, this is exactly the drift the reverse shape-coverage gate exists to catch — the API returns fields the SDK's typed shape API doesn't know about.

Changes

Two generated artifacts and a changelog entry. No hand-written code.

• contracts/filter_shape_contract.json — re-vendored via scripts/refresh_contract.py. The diff is 5 lines: relationships.source and relationships.type in the entities shape tree and flat-path list, plus a meta.api_version key (4.20.0) that the upstream contract now stamps and the vendored copy didn't previously carry.
• tango/shapes/generated_overlay.py — regenerated via scripts/generate_shape_overlay.py. The only delta is the two new leaves on RELATIONSHIPS_SCHEMA; the generator produced no other changes across the other 30 containers, which is the signal that the contract refresh was scoped to this one change.
• CHANGELOG.md — Added for the two keys; Changed for the upstream relation vocabulary shift.

The relation change needs no SDK code change, but read this

Upstream, relation stopped collapsing to affiliate for subcontracting and corporate-succession ties. It now names the partner's role: subcontractor / prime, predecessor / successor, and descendant (rather than child) on the far side of an ultimate-parent tie. affiliate survives only as a fallback for a type the API doesn't recognize. This affects the large majority of relationship entries.

Nothing breaks at the SDK's type layer — relation was and remains a str. But application code branching on the literal affiliate should move to type, which is stable. The full vocabulary table is in the entities data dictionary.

Testing

Check	Result
scripts/check_shape_coverage.py	0 total gaps, 0 NEW
scripts/check_filter_shape_conformance.py	0 errors (warnings are the pre-existing baselined gaps)
ruff format --check tango/	18 files already formatted
ruff check tango/	All checks passed
mypy tango/	no issues in 18 source files
pytest	490 passed, 1 skipped, 1 failed — see below

The one failure is a live-API 504, not a regression. tests/production/test_production_smoke.py::TestProductionSmoke::test_search_filters fails with API request failed with status 504. It's marked @pytest.mark.production / @pytest.mark.live and hits the production API directly. Verified it fails identically on clean origin/main with these changes stashed, and it reproduces consistently rather than intermittently — so it's a live-API condition worth looking at separately, unrelated to this diff (which touches a vendored JSON and a generated schema, neither of which is on the path of an HTTP search request).

Note on observed_shape_types.json

Not refreshed, deliberately. That file is derived by sampling the live API (scripts/probe_shape_types.py, maintainer-run, needs an API key), and the API change isn't deployed yet — probing now would re-record the old shape. The overlay generator therefore had no observation for the two new fields and defaulted both to str, which is correct for a type code and a source label. A maintainer probe after the deploy will confirm rather than change them.