Stacked pane layouts persist across save/restore cycles

[clanghans]

Problem

After restoring a session, multi-pane windows can end up with panes stacked — the first N-1 panes have a height of 1 row while the last pane takes all remaining space. Once this state is saved, it persists indefinitely across restore cycles.

Observed Behavior

In affected save files, the layout strings for multi-pane windows encode pane heights of 1 for all panes except the last. This pattern matches what new_pane() produces with resize-pane -U 999, which temporarily minimizes panes during creation so more can fit. Under normal operation, restore_window_properties() applies the saved layout via select-layout to redistribute pane sizes after all panes are created.

In the observed case, the stacked layout was present in every available save file, including the oldest (suggesting it entered the save history early and was never corrected).

Potential Contributing Factors

The following aspects of the current code could allow a stacked layout to enter the save file and persist:

1. No layout validation after select-layout: If select-layout fails or applies a layout that contains height-1 panes, nothing detects this. Panes remain stacked and the next save captures that state.

2. select-layout errors are fully suppressed: The call in main() uses >/dev/null 2>&1 (line 372), making any failures invisible.

3. No protection against saving during a restore: There is nothing preventing tmux-continuum (or a manual save) from running while a restore is in progress. If a save occurs after panes are created but before select-layout completes, it would capture the intermediate stacked state.

4. Self-perpetuating once triggered: Once a stacked layout is saved, restoring it applies the broken layout via select-layout (which "succeeds" since the layout is technically valid), and subsequent saves capture the same state. There is no mechanism to break this cycle.