mecatui: click-to-select a row in the TUI picker/overlay lists (skills, models, agents, MCP, schedule, etc.)

Summary

The TUI presents several selection lists — the skills picker, models picker, agents overlay, MCP prompts, schedule, team/parallel/subagent overlays — but they are keyboard-only: you move a cursor with up/down and confirm with enter. You cannot click a row with the mouse to select it. This asks for click-to-select on those agent/app-presented lists.

(The permission/approval modal is already clickable via #496; this covers the other list surfaces.)

Behavior requested

• Click a visible list row → select it (equivalent to moving the cursor to that row + confirming, or at minimum moving the highlight to it — see open question).
• Applies to the picker/overlay lists: skills (skills.go), models (models.go / models_surface.go), agents (agents_overlay.go), MCP (mcp.go), schedule (schedule.go), and the team/parallel/subagent overlays.
• Wheel-scroll within these already works (from #486) — this adds the missing click consumer.

Grounding (builds on existing infra, not from scratch)

• Alt-screen mouse is already captured; clicks are routed in cmd/mecatui/ui/update.go (MouseClickMsg case ~update.go:260).
• Open modals/overlays already receive mouse via a shared dispatch: m.modal.HandleWheel(...) (update.go:3204), mirroring HandleKey/HandleMsg. A natural implementation adds a sibling HandleClick (or extends HandleMsg) on the same modal interface so each list maps a click Y-coordinate to a row index.
• Per-list scroll/region state already exists to clamp against (e.g. skillsState.HandleWheel + its region/scroll fields, skills.go:232), so row hit-testing has the geometry it needs.
• Reuse the chrome()/region-derived coordinate discipline used by convTopRow/screenToContent (selection.go) rather than constants; add a drift test.
• --no-mouse (selection.go:105) and MECATUI_DEBUG_MOUSE conventions apply.

Grep confirms the pickers currently have no MouseClickMsg/HandleClick handlers — only wheel.

Open questions

• Single-click select-and-confirm vs. click-to-highlight then enter? Single-click-to-confirm is the modern GUI feel; click-to-highlight is safer for destructive pickers. Suggest: single click highlights, double-click (or click-on-already-highlighted) confirms — or make it per-overlay. Decide during design.
• Behavior for clicks in the overlay border/padding (no-op vs. clamp), consistent with the textarea-caret decision in #490.

Acceptance criteria

• Clicking a row in each listed picker/overlay selects (or highlights) that row.
• Coordinate mapping derives from the overlay's own region/scroll state (drift test included).
• Respects --no-mouse; MECATUI_DEBUG_MOUSE shows the row mapping.
• Per-overlay tests: click each visible row → assert selected index; scrolled list; click in padding/border (per decision); empty list → no-op.

Related / not a duplicate of

• #486 (closed) — clickable approval/plan-review buttons + URLs; shipped via #496. Did not cover picker/overlay list rows.
• #490 (open) — click-to-position caret in the prompt textarea; a different surface.
• This is the list-selection surface those two did not address.