fix: message bubble streaming status not cleared when new segment arrives

Start with src/tui/messageBubble.js and src/tui/conversationArea.js, tracing how localStreaming changes through pub/sub and how finalizeStreaming and handleInterrupt end a stream. Reproduce the case by starting the TUI and adding a system message during an assistant response. Done means the prior assistant bubble stops showing its spinner after the next segment arrives; verify the relevant behavior in the existing tests, whose paths are not named in the issue.

Summary

A message bubble's streaming status is not cleared when a new message segment arrives after it. A pending AI message that is interrupted by a system message still shows a spinner erroneously, even though the AI stream has ended.

Environment

• OS: Linux 7.0.14-23-pve
• Node.js: v25.8.1
• madz version: 1.117.0
• LLM provider: Unknown — user to confirm

Reproduction

Steps to reproduce the behavior:

1. Run npm start to launch the TUI.
2. Send a chat message that triggers a streaming assistant response.
3. While the assistant message is streaming, trigger a system message (e.g., a command that adds a system message, or an interrupt followed by a system message).
4. Observe the assistant message bubble.

Expected Behavior

The assistant message bubble's streaming status should be false once a new message segment arrives after it. The spinner should stop, and the bubble should render as a completed message.

Actual Behavior

The assistant message bubble still shows a spinner (streaming status remains true) even though a new message segment has arrived after it. The bubble appears to still be streaming when it is not.

Additional Context

The message bubble's streaming state is managed in src/tui/messageBubble.js via localStreaming, which is set from the streaming prop and updated via pub/sub. The streaming flag is set to false in finalizeStreaming in src/tui/conversationArea.js. If a system message is added after the assistant message without the assistant message's streaming flag being cleared, the bubble retains its spinner. The pendingState computation in messageBubble.js (role === "assistant" && localStreaming && segments.length === 0 && !localContent) also relies on the streaming flag being accurate.

Audit Findings (for Issue #1454)

• src/tui/messageBubble.js:498 — pendingState is computed as role === "assistant" && localStreaming && segments.length === 0 && !localContent. The spinner is rendered when pendingState is true. If localStreaming is not cleared when a new segment arrives after the assistant message, the spinner persists.
• src/tui/messageBubble.js:272,328 — localStreaming is initialized from the streaming prop and updated via pub/sub (data?.streaming). It is only cleared when a publish carries streaming: false.
• src/tui/conversationArea.js:908-944 — finalizeStreaming sets streaming: false on the message via updateMessage, which publishes to the bubble and clears the spinner. This is the normal completion path.
• src/tui/conversationArea.js:171-211 — handleInterrupt sets streaming: false on the message directly (without calling finalizeStreaming), which also clears the spinner via pub/sub.
• src/tui/messageList.js:40-51,685 — shouldRenderBubble keeps an assistant bubble visible if it is streaming OR has non-empty content/segments. An interrupted assistant bubble with only reasoning/partial segments is kept visible, so its spinner state must be accurate.

The likely root cause: when a new message segment (e.g., a system message) is added after an assistant message, the assistant message streaming flag is not reliably cleared. This can happen if the stream is interrupted or errors without finalizeStreaming/handleInterrupt firing streaming: false, or if a system message is added via addMessage (which does not touch the assistant message streaming flag). Verify that every path that ends an assistant stream clears the streaming flag on the bubble, and that adding a subsequent message segment does not leave a stale streaming: true on a prior assistant bubble.