fix: keep listening after stopping a voice-conversation reply

[or68097452-sketch]

Summary

Stopping playback mid-reply (the playback Stop button) suppressed the next listen cycle: settleAfterSpeech treated any external stopVoicePlayback() as "user chose to stop" and left pendingStartRef false — wedging an active voice conversation into idle with the mic never reopening. The user could not continue speaking until manually restarting the conversation.

An active conversation must stay live after a Stop: the button silences the current reply, and end() (which clears pendingStartRef itself) is the only path that should end the loop. The stoppedByUser sequence heuristic is removed; the loop re-arms unconditionally when enabled.

Motivation

Reported by a user: in a voice conversation, stopping the spoken reply mid-output made voice input dead — the loop never re-listened.

Test Plan

• Updated use-voice-conversation-rearm.test.tsx:
  • re-arms the microphone after an external Stop during streaming playback (regression test — previously asserted the wedge)
  • Stop while preparing / during stream discovery now asserts the mic re-arms (handle.start ×2, status listening) while playback stays silenced (stopVoicePlayback still fired, no fallback playSpeechText)
• vitest run on both conversation hook test files: 11 passed
• ESLint: 0 problems

[spfcraze]

This was generated by AI during triage.

Summary:
The diff removes the stoppedByUser check — the only reader of speechStartSequenceRef — but leaves the ref, its three write sites, and a comment that still describes the removed stop-suppression.

Problems:

• speechStartSequenceRef is still written at apps/desktop/src/app/chat/composer/hooks/use-voice-conversation.ts:465 (fallback capture), :538 (stream-start capture), and :291 (reset), but the stoppedByUser block the diff removes was its only reader — the capture exists to feed a decision the diff deletes.
• The comment at apps/desktop/src/app/chat/composer/hooks/use-voice-conversation.ts:462-464 — "only a later, external stop suppresses the next listen cycle" — describes the mechanism this PR removes: the new settleAfterSpeech sets pendingStartRef whenever enabled, so an external stop re-arms the loop instead of suppressing it.

Solution:
Drop the ref and its three write sites, and update the comment to describe the unconditional re-arm.

---

Checked against 243e804 — the tip of fix/voice-conversation-rearm-after-stop when this was written — and b3aa561, main at the same moment.