workaround: chain a state-reporting action to next-tab/next-pane binds

[GeneralD]

Part of #37.

Motivation

Issue #37 pinned the root cause: in zellij 0.44.3 the "next" family of handlers (FocusNextPane, and by extension the next-direction tab/pane navigation) never call log_and_report_session_state(), so no PaneUpdate / TabUpdate reaches the plugin and the minimap highlight freezes until some later action happens to report session state. It is an upstream bug with no release fix yet.

That investigation already evaluated two plugin-side dispositions: no push workaround (the event simply never arrives), and a pull-based polling reconciler (get_focused_pane_info(), opt-in / default-off) that costs idle round-trips.

This issue tracks a third, config-only angle that needs no plugin code, no extra permission, and no polling: chain a second action onto the user's keybinding so the binding itself triggers the missing state report.

Idea

// instead of:
bind "Super Shift ]" { GoToNextTab; }
// chain a state-reporting action so the plugin gets its PaneUpdate/TabUpdate:
bind "Super Shift ]" { GoToNextTab; <reporting-action>; }

The first action does the navigation; the second forces the session-state report that the "next" handler omits, so the highlight catches up in the same keypress. The plugin cannot rewrite a user's keybindings, so the deliverable is a documented, verified config recipe (README / first-run notes), not code.

Open questions (the investigation)

1. Which second action reports state without a disruptive side effect? Per Focus highlight doesn't follow FocusNextPane, only FocusPreviousPane #37's source reading, several handlers call log_and_report_session_state() (e.g. SwitchFocus, FocusPreviousPane). The trick is finding one that emits the report but does not undo the navigation or move focus/tab. Evaluate candidates and document the cleanest (ideally side-effect-free; failing that, self-cancelling).
2. Does the tab case have the same asymmetry? Focus highlight doesn't follow FocusNextPane, only FocusPreviousPane #37's analysis is on panes (PaneUpdate). The reported example is GoToNextTab — confirm whether next-direction tab switching has the parallel missing-report problem and that the same chaining fixes it.
3. Verify, don't assume. Reproduce with the headless harness (eprintln oracle + expect PTY, see .claude/rules/zellij-plugin-development.md): confirm the bare bind leaves the highlight stale and the chained bind makes it follow, for both the pane and tab directions.

Trade-offs vs the polling reconciler (#37)

• This (config chaining): zero plugin code, zero extra permission, zero idle cost. But it only helps the bound actions, requires the user to edit their keybindings, and a partner action with no clean side-effect-free option may not exist.
• Polling reconciler (Focus highlight doesn't follow FocusNextPane, only FocusPreviousPane #37): works for any focus change including mouse, but adds idle round-trips and plugin complexity.

They are complementary — this is the lightweight stopgap to recommend in docs; both become unnecessary once the one-line upstream fix ships.

Done when

• A verified keybind recipe makes the minimap highlight follow next-pane (and next-tab, if confirmed in Q2) without plugin changes.
• The chosen second action's side effects (if any) are documented; if no clean option exists, that conclusion is recorded.
• The recipe is added to the README (and noted as removable once the upstream fix lands).
• Behaviour confirmed via the headless harness for both directions.

Relevant context

• Focus highlight doesn't follow FocusNextPane, only FocusPreviousPane #37 — root-cause investigation (the missing log_and_report_session_state() in zellij's next-direction handlers) and the polling-reconciler alternative.
• src/lib.rs — the event subscription set; the plugin only learns of focus/tab changes through PaneUpdate / TabUpdate, which is why a report must be forced.
• .claude/rules/zellij-plugin-development.md — headless verification harness.