Task: Give the blotter its instrument grouping

Read the same rows by asset class, beside the portfolio tree and the counterparties: the rail is the classes the rows fall into, each with its count, and choosing one narrows the list to it.

• The read states a third grouping, instrument, whose rail is the asset classes the party's rows fall into, each with the number of rows under it.
• Choosing a class narrows the list to the rows whose instrument belongs to it, and the count agrees with the page.
• The screen offers Asset class beside Portfolio tree and Counterparty, and a browser case walks it.

(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 class names come from ores_refdata_asset_class_codes_tbl and the colours from the house tokens in marketdata/assetClassColour.ts, so the rail reads like the market data screens. Nothing reads the data-quality badge catalogue, which also holds an asset_class_* row for each class: it files those rows under a severity_code, a data-quality judgement that means nothing for a class. Two captures record the questions this task does not settle — An asset class is not a data-quality severity and One spelling for an asset class code.

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 blotter reads its third way. The rail offers Asset class beside Portfolio tree and Counterparty, and choosing it redraws the same rows under the classes they fall into, each node carrying the class's own name, the house colour dot and its count. Choosing a class narrows the list to it.

The class comes from the instrument's trade type, through the instrument code catalogue the read already fetches: no model change, no second read. A structure has no class, so the rail counts the classed trades and its nodes add up to that figure, which is why a party's 57 rows show 45 under six classes.

The read serves the grouping in one pass — the same rows, resliced — and the screen caches the rail separately from the list, so switching views draws at once instead of waiting or showing the previous grouping's nodes.

Two questions were left open rather than answered inside the blotter, and both are captured in the inbox: whether the data-quality badge catalogue should be the one source for a class's colour when it files classes under a severity that means nothing, and the three spellings the same class code has today.