Task: Key netting sets by their credit limit

Where one netting agreement covers trades under several credit limits, netting is restricted to the trades within one limit, so the limit is part of what identifies a netting set. The netting_set entity has no limit column, because no credit limit entity exists to reference. Model the credit limit, then add it to the netting set and to the pin that holds a set to its agreement.

• A credit_limit entity exists in ores.refdata, carrying a code, a party, a counterparty, the limit amount and a description, and it is bound to the same variability profile as its sibling reference entities.
• A netting set names a nullable credit_limit_id. When it states one, the set's party and counterparty are the limit's, and a pinned key enforces that on write.
• The import refuses a netting set whose credit limit names a different party or counterparty, and accepts one that agrees.
• A netting set that states no limit still imports and stores, because the column is nullable and ORE documents name none.
• The generated SQL, TypeScript carriers and records, and the shell commands come from the model by regeneration, not by hand.
• The local gate passes on linux-clang-release-ninja.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The credit limit is now part of a netting set's identity, so netting can be restricted to the trades that sit within one limit.

• credit_limit is a new ores.refdata entity with a code, a party, a counterparty, a limit amount and a description. It is bound to the uuid-identified-lookup profile, as its siblings are.
• netting_set carries a nullable credit_limit_id, a check that states the limit's parties are the set's, and a second pinned key that holds the set's party and counterparty to the limit's on write.
• The generated SQL, TypeScript, repositories, services, event registrars and shell commands come from the model. Regenerating the component reports no drift, so the checked-in tree is exactly what the models produce.
• The old branch's generated output was discarded rather than merged. The model changes alone were re-applied to current trunk, which is why this lands as one commit instead of a several-hundred-commit replay.

Evidence is recorded in the PR.

Captured 2026-10-03 in the product backlog; promoted preserving the UUID.