Mouse support: wheel scroll everywhere, right-click context menus

Explicitly requested - this is a real terminal app meant to work in any
terminal (the name is a naming convention, not a tmux runtime
dependency), and should be genuinely mouse-driven, not keyboard-only.
Enabled via tea.WithMouseCellMotion() (SGR mouse mode, the same
protocol nvim and most modern TUI apps use); coexists with tmux's own
mouse mode the same way it would for any other terminal app.

Scope was decided by a real, verified library constraint, not
convenience: bubbles/table exposes no way to learn its own scroll
offset (confirmed by reading its source - no YOffset accessor, the
rendered window comes from unexported fields via a second internal
layer of viewport scrolling on top of that). Mapping a click's screen
coordinates to a specific table row can't be done without reaching into
that library's private internals, which this deliberately doesn't do -
silently selecting the wrong row on a misjudged click is worse than not
supporting precise click-to-row at all.

What's shipped, the reliable subset:

- Wheel scroll everywhere there's something to scroll: tables via the
  already-exported MoveUp/MoveDown (no scroll-state assumptions
  needed), viewports via their own native wheel handling (bubbles/
  viewport already has this - nothing in the codebase was routing
  tea.MouseMsg to it yet), and vi-modal text editors via new
  viTextarea.ScrollUp/ScrollDown (bubbles/textarea has zero native
  mouse handling at all, confirmed the same way - feeds wheel events as
  repeated up/down keypresses through the same tested movement path
  h/j/k/l already use).
- Right-click opens a context menu (cmd/mitmux/contextmenu.go) - a
  horizontal strip taking over the status/help line, the same "replace
  the bottom of the screen" pattern confirmPrompt and the export/import
  prompts already use, rather than a floating popup positioned at the
  click (lipgloss/bubbletea have no compositor for splicing an overlay
  into an arbitrary screen position - not worth building just for
  this). Wired into every list-based view: history
  (view/repeater/intruder/flag-unflag/delete), rules
  (edit/enable-disable/delete), scope (enable-disable/delete). Menu
  items ARE reliably clickable, unlike table rows - the menu renders
  its own strip, so every item's width is fully known rather than
  hidden behind a library's unexported scroll state. Navigable by mouse
  click or j/k/arrows+enter; esc or right-clicking again dismisses.

Deferred, not silently dropped: click-to-select-a-different-row (same
scroll-offset limitation), and click-to-switch-pane-focus in Repeater/
Intruder (tractable via the same Y-coordinate math WindowSizeMsg
already computes, just not done yet - keyboard tab already covers it,
so lower priority than what shipped).

Verified live in tmux by injecting real SGR mouse escape sequences
directly into the pane (tmux send-keys -l with hand-built ESC [ <
Cb;Cx;Cy M/m sequences, since tmux has no built-in "synthesize a click"
primitive) against a running daemon with real captured entries:
wheel-down/up on the history table correctly moved the selected-row
highlight (confirmed via ANSI-aware capture, not just "no crash");
right-click opened the menu with the right actions; clicking directly
on a computed menu-item position correctly triggered that exact action
(clicked "delete", saw the correct entry's ID in the resulting confirm
prompt); keyboard navigation inside the menu moved the highlight
correctly; esc and a second right-click both dismissed cleanly with no
side effects; wheel events in Repeater's text pane and Detail's
viewport caused no crash and left vi-mode state intact; an empty rules
table's right-click correctly no-opped; adding a real rule then
right-clicking and clicking "disable" correctly toggled it off
(confirmed via the rendered checkmark disappearing).

go build/vet/gofmt/test/mod tidy all clean.

0 files changed, 0 insertions, 0 deletions