fix(terminal): report the measured size, so a new pane isn't stuck at 80x24

[mortenaslo]

A new session drew its program into roughly a sixth of the pane and stayed that way until the window was resized by hand. Reported as "the window is like 1/4 or 1/5 of the window, and needs a resize before it actually uses the full screen, causes texts etc to look weird".

cc @AThraen

Cause

term.onResize was registered some seventy lines below the initial fitAddon.fit() in Assets/terminal-init.js. That fit is the one call that genuinely changes the size — xterm is constructed at its 80x24 default and fit() measures the real pane — so it fired the event with no listener attached, and the host never learned the size at all.

Moving the registration up is necessary but not sufficient, and this is the half that is invisible at the call site. Read verbatim out of the shipped bundles:

xterm-addon-fit.js	fit() skips term.resize() when the proposed dimensions already match
xterm.js	resize(c,r) early-returns when c === cols && r === rows

So once the first fit has landed, every later fit is a silent no-op: the 50ms/250ms timeouts, document.fonts.ready, the ResizeObserver, and TerminalBridge.FitTerminal's own fit message included.

_lastSize therefore stayed at its (80, 24) placeholder, pty.Start created the ConPTY 80 columns wide, and AttachPty's _pty.Resize(_lastSize) re-applied the same wrong value. xterm drew ~220x55 while the program believed it had 80x24 — hence a boxed TUI painting into ~1/6 of the pane. Only a real change in element size (resizing the window, switching layout) ever fired the event again, which is exactly the reported workaround.

This affected every session type; it was just least visible in a plain shell, which only wraps at 80 columns instead of drawing a frame.

Changes

• Assets/terminal-init.js — every fit goes through doFit() (fit → postSize()), and onResize is registered before the first fit. postSize() reports term.cols/term.rows directly, deduped against the last pair, so a no-op fit re-syncs the host exactly once and a genuine one isn't reported twice. All seven remaining direct fitAddon.fit() call sites routed through it.
• Terminal/TerminalBridge.cs — new WaitForInitialSizeAsync(1500), completed by the first resize message. NavigationCompleted is not a sufficient signal on its own: the page posts its size during load, but that message reaches the host as a separate dispatcher item, so InitializeAsync can return — and the PTY be created — first. Bounded so a wedged renderer cannot block a launch.
• MainWindow.xaml.cs — LaunchSessionAsync awaits it after ApplyFontSettings / ApplyProfileOverrides (both can change the font, and cols derives from the measured advance width) and before pty.Start, so the ConPTY is created at the right size rather than corrected a frame later — which a TUI that has already painted its first frame renders at the wrong width until a full redraw.
• CLAUDE.md — new section "A fit that changes nothing must still report the size". Calling fitAddon.fit() directly is precisely the shape someone would "simplify" back to.

The resize handler now traces RESIZE cols= rows= first= under the existing DebugTerminalTrace flag. The absence of that line is the signature of this bug, and nothing logged it before.

Verification

Build clean (0 warnings), 597/597 unit tests pass.

Both shapes run against a harness stubbing the two library early-returns above:

PRE-FIX   after launch: []                     -> PTY stays at 80x24
          after resize: [[110,55]]             -> only then correct
POST-FIX  after launch: [[220,55]]             -> real size, reported once
          after resize: [[220,55],[110,55]]

Not verified: the visual result. There is no headless way to measure a WebView2's glyph metrics, so this needs one manual check — open a new Claude session and confirm the pane fills. If it doesn't, enable DebugTerminalTrace and look for the RESIZE line in crash.log; its absence would mean the page still isn't reporting.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NsYm9iLc2aRnRDfV2uZRQX

[mortenaslo]

Review addressed in 4924c96 — all four findings were real; I verified each against the code before changing anything.

#	Finding	Fix
1	Wait resolved on the pre-override size (and usually synchronously, so the queued BeginInvoke could not have run)	setOptions now carries an incrementing token, stamped synchronously before the BeginInvoke; the wait resolves only on an echo at least as new as the last token stamped
2	Unmeasurable pane could pin the ConPTY to 80×24 or a 2×1 clamp	doFit() declines to report when proposeDimensions() is undefined or the parent is 0×0
3	Dedupe pair recorded before the postMessage inside the try	Recorded only after a successful post
4	_lastSize placeholder (80, 24) vs Start's own (220, 50)	Aligned with Start

Finding 1 was the important one — thank you, the comment was describing something the code didn't do.

Two further things that fell out of the fixes and weren't in the review:

• Giving doFit() a force parameter turned every bare callback reference into a latent bug — ResizeObserver passes the entries array, requestAnimationFrame a timestamp, .then() the FontFaceSet, all truthy. Those four sites are now wrapped. (The review had cleared these as "unused args", which was correct for the previous signature.)
• With the wait gated on a token, a pane that cannot be measured would never ack, so the launch would burn the full 1.5s timeout — trading a wrong size for a dead second. The page now posts a separate optionsApplied ack; the host adopts a size only from resize and releases the wait from either, keeping both properties.

Verified with a harness modelling both sides plus the two library early-returns and proposeDimensions' undefined/clamp behaviour:

plain session       released | pty 220x55
font override       released | pty 154x55  (default font would give 220)
options, same cols  released | pty 220x55  (forced ack, no stall)
collapsed pane      nothing posted, host keeps 220x50 placeholder
collapsed + wait    released by the ack, not the timeout

Build clean, 597/597 tests pass. The visual result still needs the manual check noted in the PR body.