Batch reconnect replay into a single observable mutation

[mcintyre94]

Summary

• During reconnect, handleEvent was appending to @Observable ChatMessage.content for every replayed event, causing a full SwiftUI re-render (and a haptic) per event. For a chat catching up on many messages this meant N expensive render passes blocked on the main actor before the user saw anything.
• Introduced isReplaying, replayContentBuffer, and replayToolUseBuffer in ChatViewModel. While runReconnectLoop is active, .assistant and .user events accumulate into these local arrays instead of mutating the observable model directly.
• After each processServiceStream iteration, applyReplayBuffer() flushes the buffer with a single append(contentsOf:) — one @Observable mutation → one render pass instead of N.
• Tool-use/result linking is preserved inside the buffer before commit, and replayToolUseBuffer is merged into the main toolUseIndex on flush.
• Haptics (.medium for first text, .light per tool result) and the auto-checkpoint are suppressed during replay — both are only appropriate for live streaming.

Test plan

• New tests: runReconnectLoop_buffersContentAndAppliesInOneBatch and runReconnectLoop_buffersToolUseAndResultWithLinking verify content lands correctly after buffered replay
• Existing runReconnectLoop tests still pass
• Manually open a chat with many completed turns and verify reconnect is noticeably faster with no jank

🤖 Generated with Claude Code

[claude]

Code review

Text fragmentation across retry iterations — Wisp/ViewModels/ChatViewModel.swift

applyReplayBuffer() uses append(contentsOf:) to flush the buffer into message.content, but this does not apply the same consecutive-text-block merging that the live-streaming path performs.

The reconnect loop is designed to run multiple iterations — explicitly, when the service is still running (isRunning == true) or when the "one extra retry after service stopped" path fires. After iteration 1 flushes its buffer and clears replayContentBuffer = [], iteration 2 accumulates a fresh buffer that starts with a new .text(...) entry. When iteration 2 calls applyReplayBuffer(), that text is appended directly to message.content with no check of message.content.last, leaving two separate .text entries where the live path would have produced one.

This matters because AssistantMessageView renders each .text element in message.content as a separate AssistantTextBubble — a distinct rounded-rectangle chat bubble. Text that belongs to a single assistant response will render as two visually separated bubbles instead of one, specifically in the "one extra retry after service stop" race-condition path that this PR explicitly handles.

Suggested fix — replace the single append(contentsOf:) call with element-by-element append that mirrors the live-streaming merge logic:

// In applyReplayBuffer(), replace:
message.content.append(contentsOf: replayContentBuffer)

// With:
for item in replayContentBuffer {
    if case .text(let newText) = item,
       case .text(let existing) = message.content.last {
        message.content[message.content.count - 1] = .text(existing + newText)
    } else {
        message.content.append(item)
    }
}

[mcintyre94]

Fixed — replaced append(contentsOf:) with element-by-element appending that mirrors the live-streaming merge logic. Also added a test (runReconnectLoop_mergesTextAcrossRetryIterations) that exercises exactly the two-iteration scenario described in the review.