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.

1 files changed, 75 insertions, 0 deletions

diff --git a/PLAN.md b/PLAN.md
index 0d1d52e..fe55cf8 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -436,3 +436,78 @@ support. No code needed here, just documented clearly in the README's
 Quick start (previously this was implied but never actually spelled
 out for a phone/tablet setup, which is a real, common daily workflow
 this tool hadn't explicitly walked through before).
+
+## Mouse support
+
+Explicitly requested - this is a real terminal app meant to work in any
+terminal (not tmux-only; the name is a naming convention, not a 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, no
+mitmux-specific code needed for that part; documented clearly instead
+(README's new Mouse section) since it does need tmux's own `set -g
+mouse on` to forward events at all.
+
+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, and
+the rendered window is computed 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 therefore 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 actually shipped, chosen to be the reliable subset:
+
+- Wheel scroll everywhere there's something to scroll - tables via
+  `MoveUp`/`MoveDown` (exported, no scroll-state assumptions needed),
+  viewports via their own native wheel handling (bubbles/viewport
+  already has this, just needed `tea.MouseMsg` routed to it, which
+  nothing in the codebase was doing yet), and vi-modal text editors via
+  new `viTextarea.ScrollUp`/`ScrollDown` (bubbles/textarea has *zero*
+  native mouse handling at all, confirmed the same way - the value here
+  is feeding it as repeated up/down keypresses through the same tested
+  movement path h/j/k/l already use, not reimplementing cursor math).
+- Right-click opens a context menu - a horizontal strip taking over the
+  status/help line (cmd/mitmux/contextmenu.go), 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. That's also a deliberate simplification: lipgloss/bubbletea
+  have no compositor for splicing an ANSI-styled overlay into an
+  arbitrary screen position, and building one just for this would be a
+  lot of new, fragile machinery for what's fundamentally a nice-to-have.
+  Wired into history (view/repeater/intruder/flag-unflag/delete), rules
+  (edit/enable-disable/delete), and scope (enable-disable/delete) -
+  every list-based view. Menu items ARE reliably clickable, unlike table
+  rows: the menu renders its own strip, so every item's on-screen width
+  is fully known rather than hidden behind unexported scroll state.
+  Navigable by mouse click, or j/k/arrows + enter; esc or right-clicking
+  again dismisses without acting.
+
+Deferred, not silently dropped: click-to-select-a-specific-different-
+row in a table (blocked by the same scroll-offset limitation above),
+and click-to-switch-pane-focus in Repeater/Intruder (would need
+Y-coordinate matching against the exact same split-point math
+WindowSizeMsg already computes - tractable, just not done yet, lower
+priority than what shipped since keyboard `tab` already covers it).
+
+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 - there's no built-in "synthesize a mouse
+click" primitive in tmux's own tooling) against a running daemon with
+real captured entries: wheel-down/wheel-up on the history table
+correctly moved the selected-row highlight (confirmed via ANSI-aware
+capture, not just "no crash" - the actual background-color-highlighted
+row changed), right-click opened the menu with the right actions,
+clicking directly on a specific menu item (computed its expected X
+position from the same label-width logic contextMenuAt uses) correctly
+triggered that exact action - confirmed by clicking "delete" and seeing
+the correct entry's ID in the resulting confirmation prompt - keyboard
+navigation (j) inside the menu moved the highlight correctly, esc and a
+second right-click both dismissed cleanly without 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 (no crash, no menu), and adding a real rule then
+right-clicking it and clicking "disable" correctly toggled it off
+(confirmed via the rendered checkmark disappearing).