backlog: redesign F1 system monitor on tmux 3.7 floating panes (drop separate-server workarounds)

[ycpss91255]

BACKLOG (idea only -- not scheduled, do not implement yet)

Redesign the F1 floating system monitor on top of tmux 3.7's floating panes (new-pane), to shed the large pile of workarounds the current separate-server + display-popup design forced.

Why the current design is complex (context)

F1 binds display-popup -E -w 98% -h 98% "bash ~/.config/tmux/mon.sh". Because tmux <=3.4 display-popup is MODAL and cannot be closed by F1 from within (no close-popup reachable while the popup covers the status bar), mon.sh runs the monitor on a SEPARATE tmux server (tmux -L mon -f /dev/null) whose own F1 -> detach-client closes the popup. That separate-server choice cascaded into a chain of workarounds (all documented in STATUS-BAR.md and issues #327 / #329):

• export SHELL=/bin/bash before the first new-session (the isolated server otherwise inherits the user's login $SHELL=fish and wraps every pane command as fish -c ...).
• sleep 86400 placeholder panes + a client-attached hook (mon-populate.sh) that respawns the real commands only once a real client has attached -- because the popup's true interior size is not known until attach, and status-tool.sh's btop-vs-htop size check must read the FINAL size.
• Per-session @mon1_populated / @mon4_populated guards so re-attach doesn't restart the programs.
• _needs_build validation (pane count + bare-shell pane-index check) to detect and rebuild a degraded session.
• -f /dev/null so the isolated server does not source the outer config's hooks.

Why floating panes could simplify it

new-pane (3.7, bound to * by default) creates a NON-modal floating pane in the CURRENT server/session, behaving like a real pane. In principle that removes the reason for a separate server, and with it most of the cascade:

• No separate -L mon server -> no export SHELL workaround (inherits the real server's shell handling), no -f /dev/null.
• A real pane in the real session is correctly sized from creation -> no pre-attach vs post-attach size race -> no placeholder + deferred-populate machinery, no populate guards.
• Toggle open/close could be a kill-pane on a marked floating pane instead of the separate-server detach-client trick.
• _needs_build largely goes away (no persistent throwaway sessions to validate).

Blockers / open questions (why it is BACKLOG, not now)

1. 3.7 floating panes are explicitly EARLY/LIMITED per upstream CHANGES: currently only movable/resizable by mouse; cannot yet be swapped, resized via resize-pane, converted floating<->tiled, or restored via custom layouts. A 2x2 grid of floating panes (the mon4 large layout) may not be cleanly expressible yet -- the single-pane mon1 case is the more likely first candidate.
2. Compatibility floor: the current design runs on tmux 3.4+ (see tmux: upgrade from 3.4 (Ubuntu default) to 3.7b (built from source) to investigate F1 popup bug #327). A floating-pane F1 would either raise the floor to 3.7 (losing 3.4 compatibility -- no released Ubuntu ships 3.7 by default; 24.04 LTS is 3.4, 26.04 LTS is 3.6a), OR require a version-conditional dual path (floating panes on 3.7+, current display-popup design on <3.7). Dual-path adds its own maintenance cost.
3. Need to re-solve, in the floating-pane world: open/close toggle semantics, multi-pane grid layout, persistence of the monitor state across toggles, and the same size-aware btop/htop selection.

Decision needed before any work

• Wait for floating panes to mature (grid layout, resize-pane support) before attempting the mon4 grid, or start with just the mon1 single-pane case.
• Decide the compatibility stance: raise the floor to 3.7, or maintain a dual path. This likely gates the whole effort.

Cross-refs: #327 (tmux 3.4 -> 3.7b upgrade + the 3.7 feature list), #329 (System monitors sub-issue: current status-tool.sh / mon.sh / disk-view.sh design). This is a personal system-configuration backlog note, not a repo code change -- no PR/commit attached.