Back-to-back tool dispatches with DeepSeek-style call_N ids rendered
the second and subsequent markers as '⎿ -1 lines' (or, with a prior
defensive guard, a blank slot) because:

  * streamToolOutput resets m.toolLineCount whenever it switches to a
    new tool id, losing the previous id's count.
  * collapseShellSlot's late path was the only place the count could be
    recovered, and it derived it from m.shellOutputs[id] — which is
    only populated for shell-prefixed ids (string-gated at the
    streamToolOutput write site). call_N ids never made it into the
    map, so n fell through to -1.

Fix:

  * Add a per-id line-count stash (m.toolLineCountByID). When
    streamToolOutput is about to switch active id, it captures the
    current (toolLineCount + (toolPartial != '')) so the old id's
    value survives.
  * Thread the ToolResult's final output through collapseToolOutput
    and collapseShellSlot as a last-resort source of truth for the
    line count. This handles a tool that never streamed (the result
    is the only signal) and lets the active path use the larger of
    the live line count and the final output (so a slow tool's last
    chunk arriving in the same event as the result isn't lost).
  * collapseShellSlot's late path now falls back through
    shellOutputs -> toolLineCountByID -> resultOutput -> 0, and the
    n<0=0 guard replaces the previous '⎿ -1 lines' rendering.

Regression coverage (internal/cli/consecutive_tool_markers_test.go):

  * TestParallelBashMarkersKeepOwnLineCount: 3 parallel Bash(ls)
    dispatch with 22 lines of streaming output each, verifying each
    card's marker slot reports '⎿ 22 lines' and the transcript
    contains no '-1 lines'.
  * TestNonShellToolLateResultShowsCorrectCount: 2 back-to-back bash
    tools with no ToolProgress between them, verifying the result's
    own output drives the marker line count.

The new fields are initialized in newChatTUI and the test helper
newTestChatTUI.