Task: Add the immutable trade anchor

The anchor exists beside the wide trade as a generated immutable entity, with database foreign keys to its three classification lookups, an insert-only write, and a sanctioned tenant purge path.

• trade_anchor is immutable and keyed by (tenant_id, id); its party, counterparty and trade type are checked, and its three closed classifications are C++ enums with enforced foreign keys to immutable lookup tables.
• The generated write inserts and never replaces, so the key refuses a second write of the same trade id. The booking operation, which task 2 adds, maps that refusal to a domain error.
• A tenant purge removes anchors through a sanctioned session switch; any other update, delete or truncate is refused.
• Build, ctest, pgTAP and the local check set pass.

• Three lookup entities, entry_channel_type, counterparty_scope_type and booking_nature_type: read-only-current-state profile, :immutable:, no tenant, seeded by populate scripts. The codes are the enumerators of three hand-written C++ enums, in the manner of binding_mode; enum generation was retired in sprint 20, so there is no generator to extend.
• The anchor, trade_anchor: read-only-current-state, :immutable:, tenant-scoped, so its key is (tenant_id, id). Party, counterparty and trade type are trigger checks, because their tables are temporal. The three classifications are enforced foreign keys with :use_no_tenant:. A check requires a counterparty unless the scope is intra_entity.
• Generator: the immutable guard lets a DELETE through while the transaction-local purge switch is on (ores_utility_allow_immutable_purge_fn). The notify trigger states a null tenant for a table with no tenant.
• Hand wiring: the trading create and drop masters, the populate master, the message registrar, the anchor event mapping, the anchor RLS policies, the tenant purger, the custom type registry and the CMake source lists.

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.

• trade_trades_test.sql, trade_identifiers_test.sql, trade_party_roles_test.sql and trade_ore_envelope_view_test.sql stop at their fixture: each books a party id it never creates. This predates the task.

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.

• trade_anchor is generated beside the wide trade: immutable, keyed by (tenant_id, id), with trigger checks for party, counterparty and trade type, and enforced foreign keys to three immutable lookups with no tenant. A check requires a counterparty unless the scope is intra_entity.
• entry_channel, counterparty_scope and booking_nature are C++ enums whose values are the seeded lookup codes.
• The immutable guard admits a DELETE only under the transaction-local purge switch, which the tenant purger turns on before it deletes anchors.
• The generator now handles a table with no tenant: the notify trigger and the synthetic data generator.
• The duplicate-to-domain-error mapping moves to task 2, where the booking operation that owns it is built.
• Verified: build clean (linux-clang-debug-make); ctest 90/90; pgTAP trading_trade_anchor_test.sql 18/18; codegen tests pass; drift shows only the known trade_service.cpp clang-format diff; sweep, paste blocks, reachability, permissions, populate references, CMake, inventory, ER strict, SQL hygiene, shell scripts, lint, structure notes and site page all clean.