Task: Point every component version at its activity

Every component version names the activity that caused it through a real foreign key.

• Each trade component and instrument table carries trade_activity_id with an enforced foreign key; the bare activity_type_code on writes is gone.
• The ORE import and the booking operation pass the activity id to every write.
• The tenant purge and the drop scripts remove the activity after the tables that reference it.

• Every model whose trade_id references the trade gets a trade_activity_id column beside it (in the identity group where trade_id is grouped) and an enforced foreign key to ores_trading_trade_activities_tbl, with a parent seed that writes an activity: 58 models, by scratchpad/add_activity_fk.py. The three identity field groups gain the field.
• Nine composed constraint names run past PostgreSQL's 63-character limit; the codegen now takes :constraint_name: on a foreign key, and those models name theirs <table base>_activity_fk.
• The trade state drops activity_type_code: its transition trigger reads the type through the activity. The generated round-trip test's amendment becomes a model snippet (amend_activity) that writes an amendment activity, replacing the column-and-code pair only the state used.
• Booking writes the activity id into the booking and the state. The ORE import stamps the instrument with the booking's activity after booking (stamp_ids takes the activity id), passes it to the identifier, portfolio and additional-field writes, and sets it beside every trade_id on the instrument writes.
• The activities are created before every table that references them and dropped after.

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.

Every trade-keyed table, the components and the instrument tables alike, names the activity that wrote each version through an enforced foreign key, and the trade state reads its transition through that activity rather than a bare code. Booking and the ORE import stamp the booking's activity on every row they write; the round trip is unchanged and every imported row names its trade's booking activity.