Task: Order the page by an indexed key

The page key is built by casting the sort column to text (coalesce(trade_date::text, )) and compared as text against the previous key. A text expression over a cast column cannot use an index on the column, so the page still sorts every row its filter matches. The order is an index in name only.

This task makes the page ordered by a key an index can serve. The key is the sort column in its own type and the trade id. The page reads its keys from the current booking rows alone, ordered by trade date and trade id, and reads the other columns only for the keys the page named. A current-only index on (tenant, book, trade date, trade id) serves the book a desk reads; a second on (tenant, trade date, trade id) serves the whole book.

The measurement is the acceptance: the first page of a book of a hundred thousand trades, read through the service, in the low tens of milliseconds, with EXPLAIN showing an index scan and no sort of the book.

• A keyset page compares its sort column in the column own type, for every sortable field.
• The default order reads the page keys from the current bookings through an index, and sorts only the page.
• The first page of a hundred-thousand-trade book answers in the low tens of milliseconds through the service, and EXPLAIN (ANALYZE, BUFFERS) shows the index.
• A page after a key returns the rows an offset page returns, and the rail counts do not change.

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

• The key is text on both sides. read_blotter_page builds coalesce(<field>::text, '') and id::text, compares the pair with < or >, and states the same expressions in the ORDER BY. Every sortable field therefore sorts as text, and no index on the underlying column can serve it. A typed key means the order's value is a date, a uuid or a text value as its column states it, and the page key keeps the wire format it has.
• Even a typed order still sorts, because the page reads the view and the view joins a lateral to each trade row. The planner cannot push a sort below a lateral. So the page must read its keys from the current booking rows alone — select trade_id, trade_date ... order by trade_date desc, trade_id desc limit n — and then read the other columns for the keys the page named. The rails keep their own grouped read; they never need the order.
• The index that serves the desk is the book's: (tenant_id, book_id, trade_date desc, trade_id desc) where valid_to = ores_utility_infinity_timestamp_fn(). The second, on (tenant_id, trade_date desc, trade_id desc), serves a page with no book filter. Both are additive; no existing index changes.
• The composite's date is its own booking's, so a package page needs no special case in the index.

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.