sl0p: resolve responsive layouts against hidden panes too

A pane created after a responsive collapse/expand cycle was absorbed into a
stack, even at full width. Reported as "a new pane starts collapsed even though
the terminal is big enough", and it appeared to fix itself on resize.

The expand was never really happening. `SwapLayouts::tiled_layout_at` checked
whether a candidate layout fits by positioning it against
`tiled_panes.visible_panes_count()` -- and a stack hides every member but one.
So while collapsed, the check ran with a pane count of 1, and a layout with no
room for the hidden panes passed as feasible. The tab reported
`sl0p:responsive-expand` while every pane stayed in the single rect it had while
collapsed; the next pane added simply joined that stack.

Feasibility is now checked against every tiled pane, hidden or not, which is the
count the layout actually has to accommodate. Only the responsive collapse/expand
resolves layouts through this function -- ordinary swap-layout cycling has its
own body in `swap_tiled_panes` -- so the change is contained to the path that was
wrong.

Verified on the test box (responsive_min_cols 90) with a scripted pty that
resizes mid-session, geometry read back from `list-panes --json`:

  before   narrow(80) 2 panes   -> one rect, both 80x23        (correct collapse)
           widen to 160         -> STILL one rect, 160x44      (expand did nothing)
           add a pane           -> new pane joins the stack

  after    narrow(80) 2 panes   -> one rect                    (collapse unchanged)
           widen to 160         -> x=0 and x=80, side by side  (really expanded)
           add three panes      -> 2+1, then 2x2, then 3+2 grids, no shared rects
           wide from the start  -> unaffected
           narrow again (70)    -> collapses, as before

No unit test ships with this, deliberately. Three attempts could not make one
discriminate: the tab harness does no rendering, so nothing populates
`panes_to_hide` and both counts are equal; hiding panes by hand does not help
because the harness's expand takes the BASE path; and asserting on the resolver
directly bypasses the count, since `tiled_layout_at` uses it only for the
feasibility check and returns the raw layout. A test that passes with the fix
reverted is worse than none, so the scripted live reproduction above is the
verification, and it is written down in docs/roadmap.md to be re-run.

zellij-server 1502 pass, zellij-utils 473 pass.

0 files changed, 0 insertions, 0 deletions