feat(client): the three list pickers adopt the chrome type ramp (UI/UX v3 P4e)

[mizu-jun]

What was deferred, and what measuring found

P4b's §5.2 left the command palette, host manager and macro picker on the cell path as "safe in principle, deferred to keep the diff reviewable". One of them was not safe:

Both list pickers aligned their columns with {:<20} / {:<22} — a count of characters. That lines up only because the chrome borrows the terminal's monospace font, which is precisely the assumption the ramp removes. It was already broken before this PR for any name past the pad width and for CJK names, whose cells are twice as wide.

name_column_width replaces it: the widest measured name plus a gap, clamped so the detail column keeps a floor. A long name shortens nothing but its own column.

Two more defects this closes

• Nothing truncated. A long palette action or host name simply drew past the panel edge. Every row now goes through draw_picker_run, which truncates and draws from one measurement — the pickers' equivalent of the widget layer's draw_row_run.
• The selection marker was part of the label. "> " and " " are the same width only in a monospace font, so a prefixed marker would have shifted every selected row's text sideways once rows drew proportionally. It is its own run now, and selected/unselected labels start at the same x.

No hit-region work

Same finding as the dialog buttons in #96: none of the three pickers is mouse-hit-tested at all — mouse.rs never mentions palette, host_manager or macro_picker. They are keyboard- and AccessKit-driven. Panel sizes and row pitch stay in cells, so nothing moves.

Gates

• name_column_width is pure and tested: widest-plus-gap, the long-name clamp (a 10 000 px name cannot starve the detail column), and never negative on a degenerate panel.
• A structural test asserts no picker row goes back to a character pad spec — with comments and the test module stripped first, since they quote the old spec.

Verification

• cargo fmt --check — clean
• cargo clippy --workspace --all-targets -- -D warnings — no warnings
• cargo test --workspace — 28 suites pass, 4 new tests
• Not covered: appearance. All three panels change text size and column alignment on screen; this joins the P4/P5/P6 on-device backlog.

Observed, deliberately not fixed

The host manager and macro picker draw their row fills and every text colour from hard-coded literals ([0.35, 0.15, 0.50, 1.0] and friends) — G11 residue the token migration missed. Those rows do not answer to the colour scheme and were never contrast-corrected in P5. Changing hue and type size in the same PR would make a visual regression impossible to attribute, so it wants its own change, sized as a G11/P5 follow-up.

Still deferred after this: the status bar (cell-aligned by design — the Lua status format is column-oriented), tab-bar labels (N-3), the SFTP file-transfer dialog (cell-derived field geometry), the context menu, and the hand-written parts of ssh_tab.rs / keybindings_tab.rs.

🤖 Generated with Claude Code

[github-actions]

Coverage report

Generated by cargo llvm-cov (workspace minus nexterm-client-gpu and nexterm-i18n).