feat: batch a request's chunks through turbo in one forward pass (~2x)

[malammar]

Builds on #160. The first two commits are that PR — synthesize_batch() reuses the
bounded conds cache it introduces. Review the third commit for this change, or merge #160
first and I'll rebase.

Summary

/tts already splits long text into chunks that all share a single voice, then synthesizes
them one at a time. T3.inference_turbo is written with batch dimensions throughout and
uses HuggingFace logits processors, which are batch-correct — so those chunks can go
through one forward pass instead of N.

No queueing, no cross-request scheduling, no added latency: the chunks already exist and
already share conditioning by the time the loop starts.

Measured

P106-100, chatterbox-turbo, four chunks, both paths warmed before timing:

sequential 5.12s  ->  batched 2.62s  =  1.96x

T3 decode alone scales further, at almost no VRAM cost — the weights dominate and only the
KV cache grows:

batch	T3 time	s/item	speedup	peak VRAM
1	0.98s	0.976	1.00x	4.50 GiB
2	1.15s	0.575	1.70x	4.62 GiB
4	1.75s	0.438	2.23x	4.84 GiB
8	2.76s	0.346	2.82x	5.29 GiB

TTS_BATCH_SIZE caps it, default 4. Batch 8 leaves only ~0.6 GiB free on a 6 GB card, and
those measurements used short test strings — real chunks build longer KV caches.

Falls back rather than changing behaviour

synthesize_batch() returns (None, None) and /tts runs the existing per-chunk path when:

• the model is not turbo — only inference_turbo takes a batch;
• a seed was requested — sequential chunks each re-seed from the same value, while a
  batch draws every row from one generator, so seeded output would stop being reproducible.
  Reproducibility beats speed here;
• there is one chunk, or batching is disabled.

Any exception inside the batched path also falls back, so a failure degrades to today's
behaviour instead of surfacing an error.

Two details worth reviewing closely

Rows that finish early keep sampling. inference_turbo breaks only when every row
emits stop on the same step, so a short row continues generating after its own stop. Those
trailing tokens fall below the OOV limit and would survive turbo's own tokens < 6561
filter as audible gibberish. Each row is therefore truncated at its first stop token
before filtering.

The first batched call is slow. On a cold process it costs ~10s while CUDA loads kernels
for a batch dimension the model hasn't seen — 13.5s first call vs 2.8s steady state. The
cost is one-time, not per-shape: after warming at batch 2, fresh batch sizes of 3 and 4
ran at full speed. warmup_batch() pays it during startup so the first real request doesn't.

Worth flagging how I found that: my first benchmark compared a cold batched call against a
warm sequential one and reported a 2.6x slowdown. The implementation was fine; the
measurement was not.

Scope

s3gen still runs per row. It accepted a (2,T) batch in testing, but only with
equal-length token sequences — real chunks differ in length, so batching that stage needs
padding plus masking. T3 decode dominates the cost, so this was left out deliberately.

Only same-voice batching is implemented. Batching different voices needs per-item
t3_cond, which is a larger change.

Testing

• Gating verified: single chunk, seeded request, and non-turbo all decline and fall back.
• Output verified against the sequential path on identical input: one wav per chunk, sane
  durations and peaks, and rows confirmed distinct (not a duplicated row).
• Per-row stop truncation verified — without it, rows that finish early produce trailing
  gibberish.
• Timing measured with both paths warm.

[malammar]

Self-reviewed and pushed a follow-up commit before this is ready to look at:

1. Conds race: _resolve_conds() was setting chatterbox_model.conds and letting the caller read it back via a second statement. That attribute is shared process-wide, so a concurrent request could reassign it between the two statements and the batch would generate in the wrong voice. Now returns the Conditionals object directly instead of round-tripping through the shared attribute.

2. Unguarded index: synthesize_batch() could in principle hand back a wavs list shorter than the input list (not observed, but not prevented either), and server.py indexed it unconditionally — an IndexError/500 instead of the intended fallback to per-chunk synthesis. Now refuses (None, None) on a length mismatch, with a bounds-checked index in server.py as a second line of defense.

Re-verified on real hardware (P106-100) after the fix — 4-chunk batch still correct (rows distinct, durations sane) and 1.88x faster than sequential with both paths warm (4.99s -> 2.65s).