Fix legacy dataset manifest binding and retry loop

[hjcud]

What failed

INT03 run dcc110d7-6cb2-3909-bb9f-623b21ac90bf selected AVAILABLE manifest 7f7113c9-3b02-4098-97ec-0baa07e2b3b0. Its eight deployed object keys use the legacy loader path segment manifest_id=<UUID>, while PostgresDatasetManifestSource accepted only the newer dataset=<UUID> convention. The resulting ConfigurationError escaped the handler and the worker retried the same deterministic input five times.

Fix

• accept canonical dataset=<UUID> keys only when every object binds one identical logical dataset;
• accept legacy manifest_id=<UUID> keys only when every object binds the requested manifest;
• reject mixed, missing, invalid, duplicate, or mismatched bindings fail-closed;
• classify catalog readiness failures as JobNotSatisfiable(REQUIRED_INPUT_UNAVAILABLE), which the existing handler publishes as a non-retryable terminal FAILED result;
• preserve the canonical logical dataset ID for new-format keys;
• add a regression using the exact eight-shard Development key shape.

Verification

• python -m pytest -p no:cacheprovider tests/test_production.py -k dataset_manifest_source -q — 6 passed
• python -m pytest -p no:cacheprovider — 1245 passed, 3 skipped, 168 deselected
• python -m ruff check src tests — passed
• python -m mypy — passed
• git diff --check — passed

No schema, contract, DLQ, worker, ASG, or database mutations are included.

Closes #76