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, 43 insertions, 0 deletions

diff --git a/README.md b/README.md
index dfa9f87..13e9429 100644
--- a/README.md
+++ b/README.md
@@ -66,6 +66,10 @@ list of what's deliberately not implemented (and why), see
   read-only response views), standard vi navigation (`j`/`k`, `g`/`G`,
   `ctrl+u`/`ctrl+d`) already works - that's the underlying TUI
   library's default, not something layered on top.
+- **Mouse support**: wheel scroll anywhere there's something to
+  scroll, right-click for a context menu on the history/rules/scope
+  lists. Coexists with tmux's own mouse mode the same way any other
+  mouse-aware terminal app does. See [Mouse](#mouse) below.
 
 ## Install / build
 
@@ -225,6 +229,9 @@ below is enough to get going.
 | `s` | target scope (what gets recorded) |
 | `q` | quit |
 
+Also mouse-driven - wheel to scroll, right-click a row for a context
+menu of the same actions. See [Mouse](#mouse) below.
+
 ### Detail view
 
 `tab` switches request/response, `p` toggles pretty-printed JSON on the
@@ -417,6 +424,42 @@ Repeater and Intruder always record regardless of scope - a request you
 deliberately resend or fuzz is something you clearly want to see the
 result of, not noise scope exists to cut.
 
+### Mouse
+
+This is a real terminal application (any terminal, not just tmux - the
+name is a naming convention, not a runtime dependency) with genuine
+mouse support, not just a keyboard-only TUI:
+
+- **Wheel** scrolls whatever's focused - the history/rules/scope
+  tables, a Detail/Comparer/Decoder-output pane, or a Repeater/
+  Intruder text editor.
+- **Right-click** a row in the history, rules, or scope list opens a
+  context menu of the same actions the keyboard shortcuts already do
+  (view/repeater/intruder/flag/delete for history, edit/enable-disable/
+  delete for rules and scope). Click an item, or navigate with
+  `j`/`k`/arrows and `enter`; `esc` or right-clicking again dismisses
+  it without doing anything.
+
+One honest limitation, not an oversight: the menu always acts on the
+row that's currently *selected*, not necessarily the exact row your
+cursor happens to be over when you right-click. The underlying table
+widget doesn't expose its own scroll position, so there's no reliable
+way to map a click's screen coordinates back to a specific row without
+reaching into that library's private internals - which this
+deliberately doesn't do, rather than risk silently selecting the wrong
+one. Scroll or navigate to the row you want first; wheel scroll and
+keyboard navigation both work exactly as you'd expect.
+
+If you're running inside tmux, its own mouse mode needs to be on too
+(`set -g mouse on` in `.tmux.conf`) for mouse events to reach mitmux at
+all - tmux forwards them to whichever pane is focused once that's set,
+the same way it does for nvim or any other mouse-aware terminal app,
+nothing mitmux-specific to configure. If you ever want to select and
+copy on-screen text with the mouse instead (which an app with mouse
+mode on normally intercepts), most terminal emulators let you hold
+Shift while click-dragging to fall back to the terminal's own native
+selection.
+
 ## Architecture
 
 `mitmuxd` owns the proxy listener and the SQLite database; `mitmux` is