fix(desktop): polish list pages — Usage, Memory, and Web Search

[UncertaintyDeterminesYou4ndMe]

Sub-issue of #1303 — the visual/layout audit of the list/long-content pages (Usage / Memory / Web Search), same shape as the #1361 metric-pages pass. Based on #1478 (the DataTable scroller fix this pass traced to the shared primitive); the first commit here is that branch. Closes #1364.

Two of three pages had no usable baseline

page	before
Memory	bridge had no memory / workspaceInstructions / app.openPath channels — the story booted into two error toasts and an empty page; entry list, backup candidates and prompt preview never rendered
Usage	logs: [] + requests tab defaults to its summary Alert — no story ever rendered a DataTable, so the issue's headline theme ("DataTable overflow") had no baseline; that is also why the primitive defect in #1478 went unseen
Web search	the result list only renders after a live query — never covered

New variants per the issue's expected deliverables (empty vs populated vs long-content):

• UsageRequestsPopulated (hostile-width rows: dated preview model id, namespaced MCP tool name, full-UUID session) / UsageEmpty / existing Usage (summary-only Alert)
• MemoryPopulated (long title/content/tag sets, archived group, backup-candidate rows) / Memory (now a clean empty state)
• WebSearchResults — a play step drives the real query path against a configured-key bridge, with a long title, a bare-URL title, and a long snippet. One wrinkle worth noting: the bridge settings are built by hand because mergeSettings treats the masked apiKey sentinel as "keep current key" and silently drops it.

What the audit found (all measured, 480–1280px)

Usage — the page grid's implicit auto track let every block's min-content propagate: the five-tab bar (~453px intrinsic) and the requests table dragged the page into horizontal scroll even though both should scroll within themselves. Pinned the single column to minmax(0, 1fr) (page + tab panel), gave the tab bar its own overflow-x: auto, and replaced two hard-track grids:

• the filters row was a five-track grid (~724px min-content) behind a 900px viewport breakpoint — the settings column is narrower than the viewport, so 900–1100px overflowed. Same lesson as fix(desktop): polish metric pages — Permissions and Health #1361: wrap structurally, no guessed threshold.
• the summary strip was repeat(4, minmax(0, 1fr)) — the same hard-track division fix(desktop): polish metric pages — Permissions and Health #1361 fixed on Permissions/Health (~32px tiles at the floor) → auto-fit, full-width layout unchanged (locked by a wide-layout guard).

Web search — three unbreakable tokens (TAVILY_API_KEY hint, bare-URL result titles, long result hostnames) each widened the page at the floor → overflow-wrap: anywhere; min-width: 0 on the query/key inputs (a text input never shrinks below its intrinsic size width on its own); the mono nowrap timestamp may wrap in the narrow layout.

Memory — the prompt-preview header's trailing cluster (injection Chip + copy button) cannot shrink → wraps under the title.

Routed to #1360, not patched here

Memory still overflows at the 480px floor through the shared settings-rows primitive: a .settingsFormRow's min-content (~306px) exceeds the ~190px content column. That is exactly #1362's declared "row wrapping" scope, so it is documented on the routing issue rather than hacked per-page — and the e2e contract deliberately asserts Memory per-surface (prompt-preview header) instead of whole-page containment, with a comment explaining why.

Verification

• Two e2e contract tests (containment + tab-bar/summary geometry at the 480px floor; full-width guard so auto-fit cannot cost the wide layout). Confirmed they fail against origin/main's CSS (toHaveCSS('overflow-x', 'auto') on the tab bar).
• Full settings e2e suite 13/13; desktop unit suite 2845/2845; format / typecheck / test:checks / check-dead-css clean.
• Probed 7 stories × 480–1280px in Storybook: zero horizontal overflow beyond the documented settings-rows remainder.

Live-app screenshots

Usage and Web search at the 480px floor (summary folds, tab bar scrolls within itself, tokens wrap):

The new populated baselines — requests DataTable scrolling in its own container at 1280px, and the Memory entry surfaces that had never rendered in a story:

[Astro-Han]

Approved. The production fix is in the right places: DataTable owns its scroll boundary, and the page CSS only handles the grid and text constraints that belong to those pages. The remaining settings-row overflow is correctly left to the shared follow-up instead of being patched here.

I left two inline comments about states that the Story and E2E do not actually render. Those are coverage gaps, not objections to the implementation.

[UncertaintyDeterminesYou4ndMe]

@Astro-Han The follow-up commit (c6804b7) seems to be waiting for a maintainer to approve the workflow run — no check suite has been created on it (fork PRs appear to be gated now; base-repo PRs are still triggering fine). Local verification: settings e2e 15/15, desktop unit 2845/2845, format/typecheck clean. Could you hit "Approve and run" when you get a chance?

[Astro-Han]

Approving 89681fb. The E2E now reaches the request table and long Web Search results, and UsageEmpty opens on the actual empty state. All required checks pass.

One follow-up: settings.spec.ts calls .toPass() without a timeout. With the locked Playwright 1.61.1, this defaults to 0 and does not inherit expect.timeout, so the refresh block runs once. Please set a timeout on the call or configure expect.toPass.timeout. This is not blocking.