tmux/psmux: the session's initial window is created with no `-n`, so it is the only window bmad-loop does not name

[pbean]

Split out of #673, whose original automatic-rename diagnosis was retracted by its reporter. This is the residual that survived the retraction — a smaller and different claim than the one that issue opened with. The hang half stays on #673, awaiting the reporter's committed retest on 0.11.0 + psmux 3.3.8.

Validated against main @ cf5d5b99; every cite below was resolved by symbol.

The asymmetry

Every window bmad-loop creates carries an explicit -n <name> — except one.

site	argv
BaseTmuxBackend.new_window (src/bmad_loop/adapters/tmux_base.py:273-284)	new-window -t =<session>: -n <name> -c <cwd> -P …
BaseTmuxBackend.new_parked_window (tmux_base.py:302-310)	new-window -d -P -F '#{window_id}' -t =<session>: -n <name> …
BaseTmuxBackend.new_session (tmux_base.py:146-153)	new-session -d -s <name> -c <cwd> — no -n

The session's initial window is deliberate — the comment at tmux_base.py:149 explains it: "Window 0 is a plain shell so the session survives task windows closing." It just has no supplied name, so its name is whatever the multiplexer decides. On psmux that means auto-rename writes the foreground process name into it (pwsh in the rig posted on #673).

Why it is worth closing

Two reasons, neither dramatic:

1. Consistency. It is the only window in the system whose name bmad-loop does not control, in a codebase where window names are load-bearing everywhere else.
2. It is the only window that can still pay the auto-rename walk. psmux sets manual_rename = true on every -n path and the rename loop skips such windows before get_foreground_process_name — verified independently in the Two concurrent unattended runs preceded a machine hang (Kernel-Power 41, no bugcheck) — original autorename diagnosis retracted, see correction #673 thread on 3.3.8, with both commits in v3.3.7. So the -n windows were never affected; window 0 is the sole exception. That cost is only paid when something asks that window for #{pane_current_command} (an attached client refreshing its status bar), which is why this is a P4 tidiness item and not a performance defect.

The counter-argument raised on the thread is refuted

The worry that giving window 0 a fixed -n would break _ctl_window_candidates does not hold. _CTL_WINDOW_RE (src/bmad_loop/tui/launch.py:36) is ^(?:run|sweep|resume|resolve)-(.+)$ — anchored to four literal kinds — and two further belts sit behind it in _ctl_window_candidates (tui/launch.py:658-699): runs.is_valid_run_id on the captured group, and the PROJECT_OPTION tag / run-dir ownership check.

It does impose the one real constraint on this change: the chosen name must not be run-…, sweep-…, resume-… or resolve-…, or window 0 of the shared bmad-loop-ctl session would start matching as a run window. Anything else (shell, bmad-loop, …) is safe. It was struck through by its own author on the thread; repeating it here so it is not re-derived from scratch.

The real cost is lockstep

This is a four-site change, not a one-liner. That is the whole of the work:

• src/bmad_loop/adapters/tmux_base.py:146-153 — BaseTmuxBackend.new_session.
• src/bmad_loop/adapters/psmux_backend.py:205-243 — PsmuxMultiplexer.new_session builds the same argv independently at :227-231. It is a parallel implementation living outside the TMUX_BACKENDS quarantine set (tests/test_portability_guard.py:42, which admits only adapters/tmux_base.py and adapters/tmux_backend.py), so the guard test will not point at it — it has to be remembered.
• tests/test_tui_launch.py:103-112 — asserts the exact new-session argv as a list.
• tests/test_psmux_backend.py:262-274 — asserts the exact psmux new-session argv as a list.

One correction to the file list as it was first written on #673: tests/test_psmux_live.py:165-170 (_raw_new_session) and :233-235 (the data-dir isolation probe) build the same argv, but they are probe helpers that deliberately bypass the backend — they do not assert what new_session emits, so they need no change. Noted here only so nobody chases them.

Also worth checking while in there: PsmuxMultiplexer.new_session ends with a has_session belt (psmux_backend.py:236-243); adding -n should not disturb it.

Suggested shape

Add a -n with a fixed, non-run-shaped name to both new_session implementations, keeping the two argvs in step, and update the two argv assertions. good first issue because it is well-specified, low-risk, and the whole diff is visible from this description — but it does need all four sites touched together.

Credit: the asymmetry was found and corrected by @danieljosejunior on #673, and independently reproduced on psmux 3.3.8 by @dracic in the same thread.