🤖 Generated by AI (CnsMaple + Reasonix)

Summary

Follow-up to #3951 + #3973. Rebased onto current main-v2 (c5c3093); preserves both merged fixes in place. Adds two targeted changes to collapseShellSlot's late path:

1. Per-id line-count stash (m.toolLineCountByID). When streamToolOutput is about to switch active id, it captures (toolLineCount + (toolPartial != "")) keyed by the old id, so the count survives the reset that used to drop it on the floor.
2. ToolResult output threaded through. collapseToolOutput / collapseShellSlot now take the result's final Output and use it as the last-resort source for the line count, after shellOutputs and toolLineCountByID have had their say.

Why this exists

After #3951 + #3973, the -1 lines rendering is gone and late-collapsed slots repaint immediately. But the visual result for a back-to-back bash dispatch with real output is now a blank line under every tool that was overtaken — ● Bash(ls) / [empty] / ● Bash(ls) / [empty] / ● Bash(ls) / ⎿ 22 lines. The third tool's marker is correct (it never got overtaken) but the first two lose their line count even though the run actually produced 22 lines each.

I want to flag this as a behavioural choice, not an oversight: the #3951 review comment by @esengine explicitly says "clearing the slot instead of fabricating a count is the right call" and accepts "a blank line — visible but harmless" as the trade-off. This PR takes the opposite trade-off — always show a real line count when one can be recovered, blank only when there's truly no signal. Either is defensible; the test below is the tripwire that makes the choice explicit so the next person reading the code can see what's being committed to.

Repro before this PR

ToolDispatch  bash call_1
ToolDispatch  bash call_2
ToolDispatch  bash call_3
22 × ToolProgress  call_1 "line\n"  (pre-empted by 2 and 3 before call_1's result)
22 × ToolProgress  call_2 "line\n"  (pre-empted by 3 before call_2's result)
22 × ToolProgress  call_3 "line\n"
ToolResult     call_1 "line\n" × 22
ToolResult     call_2 "line\n" × 22
ToolResult     call_3 "line\n" × 22

Transcript on main-v2 (post-#3951 + #3973):

● Bash(ls)

● Bash(ls)

● Bash(ls)
⎿  22 lines

Transcript with this PR

● Bash(ls)
⎿  22 lines
● Bash(ls)
⎿  22 lines
● Bash(ls)
⎿  22 lines

Fallback chain in collapseShellSlot's late path

shellOutputs[id]          (only populated for "shell-" prefixed ids)
  → toolLineCountByID[id] (what streamToolOutput saw before it switched away)
  → resultOutput          (the ToolResult's own Output — covers the "never
                           streamed, result is the only signal" case)
  → 0                     (the existing n<0=0 guard from #3951 keeps the
                           -1 lines regression at bay even when none of
                           the above are available)

Active path uses max(toolLineCount, len(resultOutput)) — the live state is sometimes lower than the result's actual end-state if the last chunk of a slow tool arrived in the same event as the result, and we'd rather render the authoritative count.

Regression tests (in internal/cli/consecutive_tool_markers_test.go)

• TestParallelBashMarkersKeepOwnLineCount — 3 parallel Bash(ls) × 22 lines, asserts no -1 lines anywhere and that each card's marker slot reports ⎿ 22 lines. Pre-fix on main-v2: fails with c1 marker at transcript[1] should contain ⎿, got "". With this PR: passes.
• TestNonShellToolLateResultShowsCorrectCount — 2 back-to-back bash tools with no ToolProgress between them; the result is the only signal. Verifies the slot ends with ⎿ N lines driven by e.Tool.Output, not blank.

The pre-existing TestConsecutiveNonShellToolsDoNotRenderNegativeLineCount (from #3951) and TestConsecutiveToolCallsKeepMarkersUnderOwnCard (from #3951) both continue to pass.

Scope notes

• collapseToolOutput / collapseShellSlot signature change: id, idx → id, idx, resultOutput. The new param is plumbed from ingestEvent's ToolResult case (where we have e.Tool.Output in hand) and the other three call sites pass "" (no result available in those flows).
• toolLineCountByID is initialised in both newChatTUI and the test helper newTestChatTUI. Map entries are written only on id switches where the outgoing count is > 0; the entry is read once and discarded after the matching ToolResult is collapsed.
• Author's transcriptDirty = true inside collapseShellSlot (fix(chat): repaint late-collapsed tool slots immediately #3973) is preserved. The duplicate transcriptDirty I originally added in collapseToolOutput's active path was dropped during the rebase — the function-body assignment covers both callers and is the cleaner location.
• No CLI flag / config / model prompt change.

Label

tui — Terminal UI / CLI (internal/cli, internal/control).