Task: Answer the rail from one grouped read

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

The rail is answered by one grouped read. count_blotter_rail groups ores_trading_trade_summaries_vw by the dimension the request names, under the same filter the page takes, and trading.v1.blotter.rail returns one node per group with its count. The portfolios a book sits under are rolled up from the grouped rows, not from the trades.

Merged on main in #4403 at b903acb4. The six [rail] cases in trading/core/tests/blotter_rail_tests.cpp cover the book counts, the portfolio subtree, the filter the page honours, a list of values, a search, and the refusal of a dimension the rail does not have.

The store behind the rail is still the union view. This task gave the rail the right shape; making it cheap is List a package as the trade it is and Order the page by an indexed key.