fix: smoother streaming start via one persistent output stream

[StuBehan]

Summary

Streaming playback was rough — a bit crackly — at the very start of a response, most noticeable on Bluetooth output. The cause was per-sentence playback: each sentence was played with its own sd.play() / sd.wait(), so every sentence opened and tore down a fresh PortAudio stream. The rapid open/close at the start (short early sentences, plus the daemon reinitialising PortAudio right before the first play) is what crackled. This plays the whole utterance through a single output stream and warms the start up so it begins cleanly.

Changes

• One persistent sd.OutputStream per utterance — each sentence is written into it as soon as it's synthesized, instead of a fresh sd.play() per sentence. Gapless, no per-sentence open/close.
• ~120ms silence prime before the first word, so output-device warm-up (notably a Bluetooth codec/profile switch) lands during silence rather than mid-speech.
• ~8ms fade-in on the opening samples to avoid an onset click.
• stop() aborts the active stream — it previously relied on sd.stop(), which doesn't halt a manually-opened OutputStream.
• Tests moved to the OutputStream surface, with new coverage for the silence prime and the fade-in.

No public API change — every caller (daemon, CLI speak, library) benefits automatically.

Testing

• pytest — 179 passed; ruff check . and ruff format --check . clean.
• Real-model integration (mocked audio device): confirmed exactly one OutputStream is opened for a multi-sentence utterance, the first write is 2880 samples (120ms) of silence, and the first sentence ramps from 0.0.
• By ear: A/B'd this build against the released 0.7.0 with stackvox speak "<multi-sentence text>" — the startup roughness is gone.

Related issues

None.