fix(tools): Route select_pane next/previous via absolute pane_id for older tmux

why: CI exposed that the prior fix (server.cmd with target=
f"{window.window_id}.+") still fails on tmux 3.2a: targeting a
non-active window routes focus back to the client's current window.
The relative-pane-offset parser for scoped window targets like
@window_id.+ behaves differently across tmux releases — 3.6-alpha
resolves it correctly; 3.2a falls back to client curw. The CI
trace shows a returned pane with window_id='@1' when the call
targeted '@2', confirming the same class of misrouting the earlier
fix was meant to eliminate.

Sidestep the tmux-version variation by skipping relative-target
syntax entirely: enumerate the targeted window's panes, find the
currently-active one, compute next/previous by index with
wrap-around, and select by absolute pane_id. tmux accepts absolute
pane_ids uniformly across every version, and `pane_active` on the
target window is set regardless of whether the client is focused
on that window.

what:
- Collapse the `next` and `previous` branches into a single
  compute-by-index block. `window.refresh()` ensures
  `pane_active` reflects current state; then walk window.panes,
  locate the active one, advance by ±1 (mod len), and dispatch
  `server.cmd("select-pane", target=target_pane.pane_id)`.
- Replace the two previous comment blocks with a single one that
  explains both portability concerns (bare +/- uses client curw,
  scoped @id.+ is version-dependent).
- No test change needed —
  test_select_pane_next_previous_respects_target_window already
  verifies the correct behavior; it was failing only on older
  tmux versions because the previous fix was version-specific.

Author: tony

src/libtmux_mcp/tools/pane_tools.py

@@ -875,15 +875,26 @@ def select_pane(
     assert direction is not None
     if direction in _DIRECTION_FLAGS:
         window.select_pane(_DIRECTION_FLAGS[direction])
-    elif direction == "next":
-        # Anchor the relative target to the requested window. A bare
-        # `-t +` resolves against the attached client's current window
-        # (tmux cmd-find.c), NOT the window we're targeting.
-        # `@window_id.+` forces tmux to resolve the `+` offset against
-        # the explicit window's active pane.
-        server.cmd("select-pane", target=f"{window.window_id}.+")
-    elif direction == "previous":
-        server.cmd("select-pane", target=f"{window.window_id}.-")
+    elif direction in ("next", "previous"):
+        # Compute the target pane by absolute pane_id rather than using
+        # tmux's relative pane-target syntax. Two portability issues
+        # motivate this approach:
+        # 1. A bare `-t +` / `-t -1` resolves against the attached
+        #    client's current window (tmux cmd-find.c), not the window
+        #    we're targeting.
+        # 2. The scoped form `@window_id.+` / `.-` works on tmux 3.6+
+        #    but the relative-offset parser's behavior for prefixed
+        #    window targets varies on older releases (tmux 3.2a still
+        #    falls back to client curw for `@id.+`). Enumerating
+        #    panes and selecting by absolute pane_id sidesteps
+        #    tmux-version variation entirely.
+        window.refresh()
+        panes = list(window.panes)
+        active = next((p for p in panes if p.pane_active == "1"), panes[0])
+        idx = panes.index(active)
+        step = 1 if direction == "next" else -1
+        target_pane = panes[(idx + step) % len(panes)]
+        server.cmd("select-pane", target=target_pane.pane_id)
 
     # Query the active pane ID directly from tmux to avoid stale cache
     target = window.window_id or ""