Three root causes addressed:
1. PtyChatParser: user input echoed after a bare prompt line (e.g. "❯ \n"
followed by "hello\n") was misclassified as assistant content. Added
_awaitingInput flag that flips true on prompt boundary and classifies the
next content line as role=user.
2. Chat mode "looks stuck": when the session is idle (connected, not
streaming, has timeline content), no visual cue indicated GSD was waiting
for input. Added a "Ready for your input" indicator with a pulsing dot.
3. Transcript overflow misalignment: chatUserMessages was not trimmed when
liveTranscript/completedTurnSegments overflowed MAX_TRANSCRIPT_BLOCKS,
causing index-based interleaving to pair user messages with wrong
assistant responses.
Also exposed isAwaitingInput() on PtyChatParser so chat UIs can query
whether the session is waiting for user input, and widened the > and $
prompt marker regexes to match bare prompts after trimEnd strips trailing
whitespace.
Closes#2707
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
3e78270cad