Task: Record the equity arc status

The design states which units are merged, and why the remaining ones wait on the mapper migration.

(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 design carries a Status section. It names the five merged units and E15, with their PRs, and states what the data model now holds: a header keyed by the trade with the family's common dates, a basket stored as rows, exact money on every money column, and an identity keyed by the trade on all twelve tables.

It also records why units 6 to 11 wait. The reason is the routing. The generated trade_type_routing enum is consumed at runtime by the trade component queries and the trade export service, so pointing the equity codes at the header before the importer writes it would make both look for equity instruments in an empty table. The re-pointing, the fact tables' duplicated identity columns and the columns E7 and E8 name all move with the same mapper migration, which the operator deferred to the xsdcpp removal.

Verification is the documentation check: all 39 components pass.