fix(pty): defer initial PTY resize to recover from startup TIOCGWINSZ race (Linux/Wayland)

[aeriondyseti]

Summary

Adds a 50ms-deferred re-query + resize of the inner PTY at proxy startup, working around a TIOCGWINSZ race that strands the inner shell with stale terminal dimensions until the first real SIGWINCH arrives.

I'm running ghost-complete on Linux (Ghostty/Wayland), so this PR is firmly in "patch from a fork user who hit a platform-specific edge case" territory — flagging that up front since CONTRIBUTING.md declares the proxy as macOS-focused. Posting as draft so you can decide whether it's worth merging, ignoring, or pointing me at a better fix.

The bug

On a fresh terminal window, the first zsh prompt renders misaligned:

• zsh's PROMPT_SP indicator (%) appears at column 0 because zsh's internal cursor-column tracking disagrees with the actual terminal width.
• Right-aligned RPROMPT segments (in my case oh-my-posh's clock) land on a new line instead of at the right edge.
• Resizing the window (zoom in/out) instantly fixes everything for the remainder of the session.

Every subsequent prompt is fine.

Root cause

gc_pty::spawn::spawn_shell calls get_terminal_size() (a crossterm::terminal::size() → TIOCGWINSZ ioctl) once and uses the result to open the inner PTY. On Linux/Wayland with Ghostty, the outer terminal's window-size handshake with the compositor isn't always complete at the moment that ioctl runs, so the ioctl returns stale/default dimensions. The inner PTY is created with those dimensions; the inner shell's $COLUMNS is wrong until the next SIGWINCH.

The existing SIGWINCH handler in proxy.rs already does the right thing (re-query, resize_pty, update parser dimensions) — the only problem is that no SIGWINCH arrives during normal first-prompt rendering. Zooming "fixes" the bug only because zoom is what finally triggers SIGWINCH.

Why macOS likely doesn't see this

On macOS, AppKit's window-creation/spawn flow is synchronous enough that TIOCGWINSZ at child-process start almost always returns correct dimensions. On Linux + Wayland the spawn-then-size sequence is multiple async round-trips across the compositor, and "process alive" precedes "process knows its window size." This is the same class of bug that's bitten tmux, screen, and other PTY proxies historically.

The fix

// In run_proxy(), shortly before signal registration:
let (initial_resize_tx, mut initial_resize_rx) = mpsc::channel::<()>(1);
tokio::spawn(async move {
    tokio::time::sleep(Duration::from_millis(50)).await;
    let _ = initial_resize_tx.send(()).await;
});

// New tokio::select! branch (peer of sigwinch.recv()):
_ = initial_resize_rx.recv() => {
    // Re-query and propagate fresh size to inner PTY + parser.
    // Same as SIGWINCH branch minus the popup-overlay cleanup
    // (no popup can be visible 50ms after startup).
}

Single file change in crates/gc-pty/src/proxy.rs (+51 lines).

Trade-offs / open questions

• 50ms is a magic number. It's the cheapest thing that demonstrably resolves the symptom on my hardware. A principled v2 would poll terminal::size() until two consecutive reads agree (capped at, say, 200ms), or wire a one-shot timer that's cancelled by the first real SIGWINCH if one arrives early. Happy to rework if you'd prefer a less timing-coupled approach.
• No regression test. This race is hard to simulate in a unit test — you'd need to mock TIOCGWINSZ returning stale values for ~30ms then catching up. A weaker test (assert a second resize_pty call happens within 100ms of spawn, regardless of value) would at least pin the behavior. Let me know if you'd like one and I'll add it.
• If the initial size was already correct, the deferred resize is a no-op (resize_pty with same dims doesn't emit anything to the inner shell). So this is a free defensive layer for macOS users too — but I haven't tested on macOS.
• The popup-cleanup path is omitted from the new branch because no popup can be visible at the 50ms mark. If you'd prefer symmetry with the SIGWINCH handler, happy to factor the common body into a helper.

Verification

Manually verified on Ghostty 1.x / Linux x86_64 / Wayland: with this patch, fresh windows render the first prompt correctly without any zoom workaround. Built with cargo install --path crates/ghost-complete --locked --force and exercised across ~20 fresh windows.

cargo fmt --check passes on the changed file. cargo clippy -p gc-pty --all-targets -- -D warnings passes on the changed file (there's a preexisting clippy warning in gc-overlay/src/render.rs:67 from clippy 1.93's stricter doc-list rules — unrelated to this PR, worth a separate cleanup).

Test plan

• Open a fresh Ghostty window on Linux — first prompt aligned, no % indicator
• Repeat 5+ times to confirm not flaky
• Verify no regression on macOS (I cannot test — would appreciate a Mac-side sanity check)
• Verify popup behavior unchanged (the new branch doesn't touch the overlay path)