Support multiple catalog entries per runtime contract

[mborodii-prog]

Summary

Allow lookup, lookup.key, and lookup.semantic to retain their catalog IDs (81, 101, 102) while sharing one lookup runtime contract and documentation page.

• Preserve the canonical contract identity using catalog_key = wrangle_key, independently of snapshot order.
• Publish a checksummed catalog/bindings.json artifact linked from the manifest.
• Add the supplied lookup catalog rows to the snapshot.
• Keep catalog IDs and keys unique, validate binding kinds, and report additional bindings in reconciliation.
• Bump Registry to 0.3.1 and regenerate artifacts. Existing contracts change only their Registry version; executable keys and Recipe Writer eligibility remain unchanged.

The snapshot now contains 101 catalog entries, with 100 bindings to 98 callable contracts. map remains catalog-only.

Validation

• npm run check:registry — 20 tests passed; 336 generated artifacts current.
• npm run build — passed.
• git diff --check — passed.

Regression tests cover shared contracts, preserved selection identities, order independence, BIGINT precision, duplicate IDs/keys, missing or invalid canonical mappings, and incompatible kinds.

Scope

No database migrations, API/Rai consumer changes, or deployment. Consumers selecting subtype catalog IDs must read the new bindings artifact and obtain the saved model ID separately from authorized model metadata.

Related to #32.

[ebhills]

These core lkup variants need their own documentation and probably even the runtime contract. What I mean is that we should implement lookup.key and lookup.semantic. We already sort of do this for extract with extract.ai and extract.custom