Task: Page the blotter by keyset

(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 page is a keyset read. read_blotter_page reads one page after a key the service itself wrote: the sort value and the row id, joined by a separator no value holds. The default order is the trade date, newest first, then the id. A page with no key is the first page. trading.v1.blotter.page carries the key back to the screen, and is_sortable refuses a field the order cannot state, so the page and the list cannot disagree about what an order means.

Merged on main in #4403 at b903acb4. The four [page] cases in trading/core/tests/blotter_rail_tests.cpp cover a page of five read in twos, a page after a key, the page's agreement with its rail, and every sortable field stating a key.

Two costs remain, and they are not this task's: the key is compared as text, so no index serves the order, and the page reads the union view, so it pays for each row's laterals. List a package as the trade it is and Order the page by an indexed key carry them.