[FEATURE] Re-run statusLine command on terminal resize (SIGWINCH)

Still relevant on 2.1.268.

The docs now tell scripts to read COLUMNS and LINES, which invites width-adaptive layouts, but the "When it updates" list still has no resize trigger. So a right-anchored segment padded for the old width stays on screen after a drag until the next assistant message.

Reproduction:

1. Configure a statusLine command that pads to COLUMNS (printf '%*s' "$COLUMNS" "model" is enough).
2. Start a session and wait for the first render.
3. Widen the terminal. The padded text keeps the old right edge.

Scripts cannot work around this from inside the output. Cursor-positioning CSI sequences such as \e[<col>G are sanitized (#64565), and leading whitespace is trimmed, so only SGR colors survive.

The only workaround today is refreshInterval: 1, which re-runs the script every second whether or not anything changed. A resize trigger could reuse the existing 300ms debounce, so the script would run once when the drag stops.

Still reproducible on 2.1.270, the latest release on npm as of 2026-09-14 (macOS, Terminal.app, native install). Adding measurements of the refreshInterval workaround, and a pointer to where resize handling already exists.

What the workaround costs. I use a right-aligned bash status line with refreshInterval: 5:

• One run of the script takes ~21 ms (~17 ms CPU). With 8 sessions open, the script alone costs ~2.7% of a core around the clock, idle sessions included, to catch the occasional resize.
• After each resize the old layout stays on screen until the next tick. From the end of a drag to the corrected render I measured 2.9 s (281 → 252 columns) and 1.5 s (252 → 279). The worst case is the interval plus the 300 ms debounce.
• Both re-runs rendered correctly at the new width. COLUMNS and the script are fine; the only thing missing is a trigger.

Resize handling already exists next door. subagentStatusLine receives a documented columns field. In the 2.1.270 bundle, the logic that drives it also takes the terminal width as an input, so it re-runs when the width changes. The state changes that trigger a main statusLine update (token usage, permission mode, vim mode, model, fast mode, effort, thinking, PR status, a new assistant message) don't include the width. Adding it there, behind the existing 300 ms debounce, looks like it would be enough to close this.

Still reproducible on 2.1.296 (macOS, native install, tui: fullscreen). The comments above cover widening; narrowing is worse, because the layout doesn't just sit in the wrong place — it loses content.

The status line text is drawn with wrap: "truncate", which cuts from the end. A line padded to the old COLUMNS is wider than the new terminal, so it's truncated from the right with …. With a right-aligned layout, that drops exactly the segments the padding was there to anchor (in my case cache state, model and session cost), while the padding in the middle survives. The row stays like that until the next trigger.

Repro:

1. Set a statusLine command that prints left, then spaces up to COLUMNS - 4, then right.
2. Wait for the first render, then make the terminal ~30 columns narrower.
3. Expected: left … right re-laid out at the new width. Actual: left …, and right is gone until the next assistant message or refreshInterval tick.

No output-side workaround exists: cursor-positioning CSI is stripped, leading whitespace is trimmed, and right/center alignment was closed as not planned (#64565). So padding to COLUMNS is the only way to right-align, and it depends on a re-run when the width changes. In 2.1.296 the update triggers are still token usage, permission mode, vim mode, model, fast mode, effort, thinking, PR status and a new assistant message. Adding terminal width there, behind the existing debounce, would fix both directions.