TUI: add mouse event support: clicking and wheel scrolling

[lukstafi]

Summary

• Mouse left-click on a visible item row selects it; click on already-selected expandable item toggles expansion
• Mouse scroll wheel moves cursor up/down by 3 items
• Mouse events ignored during input modes (search, goto, quiet path)
• DB-backed TUI supports click <n>, scrollup, scrolldown via parse_command_string
• Term.create ~mouse:true made explicit; footer help text updated

Closes #103

Test plan

• dune build passes
• dune runtest — no regressions from this change
• Manual TUI test: click rows, scroll wheel, verify input mode ignores mouse
• tmux with set -g mouse on

🤖 Generated with Claude Code

[lukstafi]

Refactor Notes — Mouse Support (#103)

What I'd do differently next time

1. Extract a shared scroll helper: ScrollUp, ScrollDown, QuarterUp, QuarterDown, PageUp, and PageDown all follow the same pattern — compute new cursor, clamp, adjust scroll offset. A small move_cursor_by ~delta ~content_height state helper would eliminate the repetition and reduce the surface for off-by-one bugs.

2. Return row-to-item map from render_screen instead of a module-level ref: The last_row_to_item ref works but is implicit coupling between render_screen and parse_key. A cleaner approach would be to have create_tui_callbacks own a local ref and thread it through both closures, or return a record from render_screen. This keeps the state explicitly scoped rather than module-global.

3. Consider scroll-only wheel behavior: Currently scroll wheel moves both cursor and viewport (matching the cursor-centric model). An alternative is viewport-only scrolling where the cursor stays put until the user clicks. This is how most GUI tree views behave. Worth revisiting if users find the current behavior surprising.

4. Scroll step could be configurable or proportional: Hardcoded 3 works for now, but max 1 (content_height / 8) would scale better on large terminals. Not worth doing now but worth noting.

5. Add parse_command_string unit tests: The DB-backed client path now accepts "click <n>", "scrollup", "scrolldown" but there are no automated tests for parse_command_string. Adding a small test module with known inputs/outputs would catch regressions cheaply.