[maximmaxim345]

What does this implement/fix?

With sendspin serve --workers, a listener joining a worker that had no other listeners heard nothing for about 5 seconds while another worker was already playing. The idle worker dropped all audio until its first listener arrived, so the first audio it sent was scheduled about 5 seconds ahead.

Workers now keep the audio that hasn't played yet, without encoding it, and hand it to a new stream so playback starts right away.

Related issue (if applicable):

Types of changes

• Bugfix (non-breaking change which fixes an issue): bugfix
• New feature (non-breaking change which adds functionality): new-feature
• Enhancement to an existing feature: enhancement
• Breaking change (changes CLI options, settings, hooks or the protocol in a way that is not backwards compatible): breaking-change
• Refactor (no behavior change): refactor
• Documentation only: documentation
• Maintenance / chore: maintenance
• CI / workflow change: ci
• Dependencies bump: dependencies

[Copilot]

🔵 Needs a closer look

Mock-only tests do not verify the pinned aiosendspin PushStream history and timestamp semantics needed for prompt, synchronized playback when joining an idle worker in a real multi-worker session.

No open issues 🎉

What changed in this PR

Fixes the roughly five-second playback delay when the first listener joins an idle worker while another worker is already playing in sendspin serve --workers.

Changes:

• Retains unplayed audio without encoding it and supplies it as history when a new stream starts.
• Discards expired chunks and clears retained audio when the source timeline changes.
• Adds tests for replaying recent audio and excluding chunks from a previous timeline.

File	Description
tests/​serve/​test_worker.py	Tests historical audio replay and timeline reset handling.
sendspin/​serve/​worker.py	Buffers unplayed audio and prepares it for newly active streams.

_{Review effort: Balanced}