Usage traces: hide zero-token sessions and sort all columns

[lvwerra]

Closes #126

What changed

• Hides only session rows where raw tokensIn, tokensOut, and cacheRead are all zero. Input-only, output-only, and cache-read-only rows remain visible.
• Keeps the server-provided aggregate unchanged and last, including in the new successful-empty state.
• Makes all eight existing headers native keyboard/pointer controls. Agent names use case-insensitive natural ordering; numeric columns use their raw fields; unknown activity timestamps stay after known timestamps in either direction.
• Preserves newest-first as the default, toggles the active column, exposes aria-sort and a visible direction arrow, and retains the selected sort and keyboard focus through rerenders.
• Adds a pure filter/sort helper plus browser coverage of the actual Usage panel.

Deliberately unchanged

This stays within the agreed per-session Traces-table boundary. It does not change provider usage/quota cards, trace parsing or accounting, API responses, polling, persisted settings, columns, or the broader Usage-page design.

Evidence

Sorted on raw token input (descending):

Successful response with no token-bearing sessions (the server total remains):

Verification

• npm test -- usageTraces — 1/1 suite passed
• npm test — 24/24 discovered web suites passed (the runner reported its three pre-existing manual render suites as skipped)
• npm run typecheck — passed
• npm run build — passed (existing bundle-size advisory only)
• Mutation check: the focused suite failed when zero-token filtering was replaced with unconditional inclusion, and failed when Tools was changed from raw toolCalls to prompts; both mutations were reverted before the passing runs.

[lvwerra]

Review of #135 against #126. Checked out 112d4d1 (based on ef08e84, the exact main commit the issue cites, so none of the issue's line pointers had gone stale) and ran the branch rather than reading the diff alone.

No findings. The change is correct and stays inside the agreed Traces-table boundary. Details of what was checked, so the empty review is not taken on trust:

Sorting, in the real app (PR build served by the server on a throwaway data dir, Settings → Usage, traces endpoint intercepted with a fixture of nine sessions: a zero-token row that is also the newest, 9/20/999/1000/1040 across every numeric column, alpha/Alpha/agent 2/agent 10, two rows tied on turns and on lastTs, an unknown-timestamp row, and input-only / output-only / cache-read-only rows).

• All eight columns sort correctly in both directions; direction toggles on re-activation by click, Enter, and Space, and a different column starts in its specified direction (agent ascending, everything else descending).
• Ties are deterministic (name then id, and independent of input order). Unknown lastTs stays last in both directions. Natural, case-insensitive name order holds (agent 2 before agent 10).
• Hiding and sorting compose: the zero-token row is hidden even though it would top the default newest-first order; the input/output/cache-only rows all stay visible. The filter works on raw fields, so 1000 and 1040 (both displayed as 1.0K) sort correctly.
• aria-sort and the arrow track the active column; the clicked/keyed header keeps focus after the rows reorder. The traces request fired exactly once across all sorts. Provider cards and the total row are unchanged by sorting. At 360px the page has no horizontal overflow and the table scrolls inside its container.
• The real (unmocked) endpoint on a fresh data dir returns no sessions with a non-zero total; the table shows “No sessions with recorded tokens” with the server total still last.

Verification claims: npm run typecheck passes, web/test/usageTraces.test.mjs passes, npm test reports 24 suites passed with the three *.render.test.mjs suites skipped as usual, and npm run build passes with only the pre-existing chunk-size advisory. The new test is in normal discovery.

Does the test actually fail without the fix? I ran twelve mutations against the focused suite: unconditional inclusion, ignoring cacheRead, ignoring direction, dropping the tie-break, dropping the unknown-timestamp handling, lexical numeric comparison, case-sensitive names, agent-first-descending, no direction toggle in the panel, no empty row, no aria-sort, and reversing the input before sorting. Eleven were caught. The only survivor is the input reversal, which is expected: the comparator is a total order, so the output cannot depend on input order. That is the determinism the issue asks for, not a coverage gap.

Scope: only UsagePanel.tsx, the new lib/usageTraces.ts helper, the .traces-table CSS block, and the new test are touched. No server, API, parsing, polling, persisted-preference, provider-card, or column changes. Server rows always carry numeric fields (emptyStats() in traces.js), so the helper's !== 0 and subtraction comparisons are safe on real data.