Task: Hold the blotter row as a projection

(Describe what user-visible-or-internal change this task produces.)

(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.

A projection was built — the table, its indexes, a rebuild function, and a measurement of 6 to 11 ms against 260 to 320 ms from the view — and then closed without merging.

It treated the symptom. The blotter row is an expression because the model has two spellings of "many trades as one" and neither is the row the screen shows. Trade Structures and Deal Composition settles it: a structure is one deal whose legs are themselves trades, and this tree's CompositeTrade is that structure. So the row is a trade, its columns are its own facts, and nothing needs copying.

The projection branch is deleted. The blotter lists trades carries what replaces it.