Story: Split the trade into an anchor and its components

Implement sections 1 to 3, 6, 9, 10 and 13 of the trade shape investigation: the anchor, the booking, the state, identifiers, party roles and additional fields, with ORE import resolving to entities and export regenerating them.

• trade is an immutable anchor keyed by tenant and id, carrying party, counterparty, trade type, the two classification values and origin.
• trade_booking and trade_state are temporal components keyed by the trade; every identifier scheme, ORE's Trade/@id included, is a trade_identifier row.
• external_id, product_type, the five field groups and the trade envelope tables are gone; trade_additional_field holds AdditionalFields.
• ORE import resolves the envelope to entities and rejects what does not resolve; export regenerates it; the round trip stays lossless.
• No trading entity carries a workspace.
• The trade-type check lists and the routing from trade type to instrument table are generated from the trade-type catalogue, not written by hand in each model.
• The anchor is the first immutable entity, so its build compiles the generated insert-only repository write, and the booking operation maps a second write of the same trade id to a domain error rather than a raw unique-key violation.
• A tenant purge that removes trades has a sanctioned path past the anchor's immutability guard, in the manner of the version-replace session switch; nothing else may update, delete or truncate an anchor.
• The drop and tenant purge scripts remove the tables that reference the anchor with an enforced foreign key before the anchor itself.
• A booking names a virtual book only while its trade is a pre-agreement draft, a test or a hypothetical; going live needs a real book in the same write.

• Build beside, then switch (owner's choice): the anchor and its components are new generated entities next to today's wide trade; each consumer moves onto them in its own pull request; the wide trade, its field groups and the envelope tables are removed last. Every pull request builds and passes, so main is never half migrated.
• While the wide trade exists the anchor is named trade_anchor; it takes the name trade in the last task.
• The anchor's origin is entry_channel (owner's choice): how the trade reached the firm's books — manual, stp, ecn or allocation. The name avoids booking_origin, which the data quality origin dimension already uses. The originating system's own id is an identifier scheme and its version belongs to the agreement.
• entry_channel is a C++ enum backed by a lookup table, with a foreign key (owner's choice). The anchor is immutable and a database foreign key needs an immutable target, so the lookup is an immutable table with no tenant, seeded once with the four codes. The enum and the lookup hold the same closed set: a code with no enum value cannot be added at run time. counterparty_scope and booking_nature are closed sets of the same kind and follow the same pattern.
• A booking's netting set is pinned to the trade's counterparty and party. A netting set read from an ORE document names neither, so the ORE import task fills the set's parties from the trade it imports.
• An ORE document's CounterParty name is an alias of a real counterparty (owner's choice), held as a counterparty identifier under an ORE scheme: the ORE samples' placeholder names map onto GLEIF banks, and the import resolves an envelope's counterparty through the alias, rejecting a name that resolves to none. A netting set answers to an ORE id the same way, through a netting set identifier (owner's choice, replacing the earlier choice to create a missing set on import): the ORE sample netting dataset publishes realistic agreements, sets, CSAs and the aliases the samples expect, and an id that resolves to none rejects the trade.
• Task order: the anchor; booking and state; the booking operation, which writes all three in one transaction; identifiers, party roles and additional fields; catalogue-generated trade-type checks and routing; ORE import and export; the remaining consumers; removal of the wide trade.
• An import rollback closes the bookings it wrote rather than deleting trades: the trade row is immutable, and a trade with no live booking is in no book and no export. A trade whose later writes fail has its booking closed the same way.
• The tenant purge deletes every tenant-scoped trading table in a loop that retries a table its referrers still hold, disabling each table's delete rules from the catalogue, and passes the trade's guard only through the immutable purge switch.
• pgTAP runs under a role row-level security binds; the owner bypasses it.

Done: the trade is an immutable row with temporal components, and the wide trade is gone.