feat(web): status tabs and the rule that placed each order (#700)

[eaitbrahim]

Most of #700 was already shipped. The issue's "Context (verified)" says there is no /api/orders endpoint and no Orders view; both have existed since #659, along with expected-vs-actual fill, the divergence and whether it went against keel, fee with a charged/modelled flag, the placement record, venue_order_id, and #626's submit-time book. What was actually missing was two things, and this is those two.

THE STATUS FILTER. gather_orders(status=), applied in the same pass as the scope so get_orders() is still called with no arguments at all -- the load-bearing pin in that function is unchanged, and its reason was always about MODE rather than about filtering in general. Server-side because a client filtering the page it received under ?limit= would be filtering fifty rows and presenting the result as every canceled order: the same argument that already puts ?sort= here.

An unknown status is applied, not refused. ?sort='s columns are a closed set this code declares, so an unknown one is a client bug worth a 400; a status is written by whatever placed the order, and _ORDER_STATUS_STATES already carries cancelled beside canceled because spellings differ. A refusal would reject a status some book genuinely holds. An unmatched filter comes back empty saying which emptiness it is, which shows a typo as plainly as a 400 and cannot be wrong about a real word.

Three new report fields, each because a number already on the page would otherwise be quietly wrong:

• statuses -- every status in the WHOLE book, which is what a tab bar is built from. Scoped, the Canceled tab would disappear on a quiet day and return tomorrow, and a control that comes and goes is worse than one that is sometimes empty. Same reasoning as modes.
• filtered_count -- scoped_count keeps its meaning (rows in the WINDOW), so a filtered view needs its own denominator. Without it "2 of 3 filled" counts rows from other tabs: every number true, the sentence false.
• empty_reason: "status" -- a fourth way to render zero rows, and a fourth sentence. Reusing the empty-book wording would tell a reader keel has never traded on a deployment whose book is full. Checked widest-cause-first, so an empty book is never blamed on the open tab.

The note is a FIXED string that does not echo the requested status. ?status= is caller-controlled text; it crosses in status, which the client places as a value.

THE RULE THAT PLACED IT. rule_id alone is a foreign key -- a number a reader cannot act on. The name is rules.kind, the same string build_rule_track_record calls rule_name, so the Orders table and the track-record table cannot name one rule two ways. Resolved from ONE read of the rules table, passed down as a map: a per-row lookup would be one query per order against a book capped at MAX_ORDERS_LIMIT, and would be invisible on any fixture small enough to read, so there is a pin on the read count.

rule_name_detail separates two absences that both render as an empty cell: no rule was recorded against this order, or a rule was and that rule has left the book. Only the second is worth investigating. That second state cannot be written through keel today -- orders.rule_id carries a FOREIGN KEY and db.connect enables PRAGMA foreign_keys = ON -- so its test drives _row_from_dict directly rather than being refused by SQLite instead of by the code under test. The branch stays: the map can also miss for a row from an older keel, an external sqlite3 session with the pragma off, or a partial map.

WHAT IS NOT HERE, AND WHY. #700 also asked for per-order quote provenance and client_order_id. Neither is recorded anywhere: the provenance strings exist only as confirm-gate banners (confirm.py:33-36) describing a preview shown to a human, and client_order_id is not a column. Both are split into #715 to be captured at placement first -- deriving either here would put a figure on the page that no record supports.

The third omission is a refusal, not a gap: #700 asked for a disclosure exposing raw_response, and payload.py now records why it will not. The column holds whatever the venue chose to send -- session metadata, internal identifiers, error schemas nobody here has read -- and the service's reduction to venue_order_id exists so that emitting the rest is impossible here rather than one line away. What would reverse it is a curated, named set of venue fields, which is a different feature with its own review.

What & why

Tests-first evidence

• Tests written first, seen failing for the right reason

Gates (all must pass)

• uv run ruff check clean
• uv run mypy clean
• uv run pytest -q green

Scope check

• This PR touches a rail or a default classification — checked means it DOES;
  leave checked only if true, and if so: cite the source and open the discussion
  BEFORE review (CONTRIBUTING.md, "Governance: rulings vs. machinery").
• New dependency added (needs discussion first)