Task: Build the published curve screens

The published curve screens read the service and match the signed-off prototype.

• The list and the record page render from real reads, with the last-N overlay and the comparison.
• History shows the record's versions with the decision merged.
• The requests queue carries the publish subject in the row.

Three units, each committed and verified on its own.

1. The reads and the model. The end facts go on the publish record: a withdrawal is a new version carrying the account, the instant, the reason and the request that authorised it, and a supersession links the successor's request and its as-of. The state is read off those facts and stored nowhere. Two new operations serve the screens: the tenant's published sets with the filters and the pager, and one series' last sets with the pillars each holds.
2. The web. The list at the market data area, the record page with Details, Published points, Compare as of and History, the routing and the words in three languages.
3. The queue subject. The BFF joins the market data component's own subject into the requests it holds, and the Requests row and the opened request draw it.

The transitions, and why. A withdrawal is an operation of its own (marketdata.v1.ops.withdraw_curve): it names a withdrawal request, not a publish request, so the publish gate's single-use rule is untouched. A supersession is not an operation at all, because the journey states that a replacement is a publish whose subject is the successor: the successor's own apply ends the sets it replaces, in the same transaction, so a series never holds two live sets.

What is deliberately not here. The zero-approval publish path, the publish notice and the maker and checker pair on the kind are a later task. The withdrawal's own raise, and the withdrawal kind's approval count, are the other journey's screens: the operation records whether a request authorised the act and enforces that a request ends one set, and it applies the act at once when no request is named.

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.

Built as three units, each committed and verified:

• 172faff715 the end facts on the publish record, the two reads and the withdrawal, with the reference suites.
• f5c14cb92b the list and the record page with its four tabs, the overlay, the comparison and the history, with the routing, the words and the BFF routes.
• c9e586c2dd the publish subject in the queue's row and in the opened request.
• 1ba0bbcad8 the two permission and history doors the live run found, and the decision stated as a gap.

The zero-approval publish path, the publish notice and the maker and checker pair on the kind are not built, as the task states: they are a later task.