fix: replace metadata-based offset compensation with CBR byte-count math

[hcgiub001]

Summary

Replace the inter-chunk offset_compensation logic with exact arithmetic
derived from the actual MP3 byte count. This eliminates cumulative subtitle
timing drift on long texts (~3 min drift at ~4 hours).

Problem

Communicate.__stream currently derives each chunk's offset baseline from the
previous chunk's last metadata offset + a hardcoded 8_750_000-tick (~875 ms)
padding constant. Three things cause this to accumulate unbounded error:

1. Microsoft's integer-overflow bug — raw Offset values in
   audio.metadata become unreliable on long texts, so
   last_duration_offset is incorrect as source material.
2. Variable AI pauses — the silence between chunks depends on content,
   punctuation, and prosody. No single constant can model it.
3. Circular error compounding — each chunk's compensation is derived from
   the already-compensated previous chunk. Per-chunk errors feed forward.

Fix

The output format audio-24khz-48kbitrate-mono-mp3 is 48 kbps CBR.
For any constant-bitrate stream, the byte-to-duration conversion is exact:

ticks = total_bytes × 8 × 10,000,000 ÷ 48,000

Every WebSocket binary message — including encoded silence from the AI's
variable pauses — is counted. The "unpredictable pauses" that defeat the
fixed-constant approach are automatically and precisely accounted for because
they exist as real MP3 frames in the audio payload.

What changes

File	Change
constants.py	Add TICKS_PER_SECOND = 10_000_000 and MP3_BITRATE_BPS = 48_000
typing.py	Add chunk_audio_bytes and cumulative_audio_bytes to CommunicateState
communicate.py	Count audio bytes per chunk; at turn.end, compute offset_compensation from cumulative byte count instead of metadata + constant

What does NOT change

• Intra-chunk word/sentence boundary offsets still come from Microsoft's
  metadata (accurate within a single chunk).
• SubMaker, save(), stream() API — all unchanged.
• last_duration_offset is still set for backward compatibility / debugging.

Why this is correct

Property	Old approach	New approach
Inter-chunk offset source	Last metadata offset + 875 ms constant	Actual MP3 bytes × exact CBR arithmetic
Affected by MS integer overflow	Yes	No — metadata not used for accumulation
Handles variable AI pauses	No	Yes — silence is encoded in the bytes
Error accumulation	Compounds per chunk	Zero (byte count is independent)
Mathematical guarantee	None	Exact for CBR; integer division, no rounding

The only scenario where this could break is if Microsoft switched to VBR
encoding, which would require a different outputFormat string — trivially
detectable.

Testing

Validated on texts producing up to 50 minutes of continuous audio with
real-time word-boundary tracking against actual playback position.
Zero observable drift. SRT timestamps remain synchronized with the audio
throughout.

[rany2]

Why close this?

[hcgiub001]

thought you wasn't interested since it's been days

[hcgiub001]

thanks for merging, sorry I caused you issues