Task: Point the grouping screen at the completion

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

• The grouping route completes the structure in one call, and writes no structure or member of its own.
• Two trades grouped together become one structure whose every leg is live and waiting on Operations.
• A refusal from the completion reaches the screen as its own message, and nothing is left behind.

One edit, in one place: the grouping route's structure-then-members loop becomes a single call carrying the anchor and the legs.

The decision the arc left open is taken here — grouping completes. The screen is called Group trades and its purpose is to make one deal out of trades already booked; a grouping that left its legs as drafts was the screen doing half its job. The draft flow keeps its place: booking a trade that waits, or adding a leg to a structure that is already live.

What the route keeps is its own checks: the session works for a party, every trade is one this session can read, all legs share one counterparty, the kind exists, and no trade is already grouped. The completion decides everything that needs a transaction.

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 completion has a caller: grouping trades makes one structure whose every leg is live and waiting on Operations.