chore(voice): report real wav duration, ignoring a streaming placeholder header

[wine-fall]

What

wav_seconds reported a bogus, constant duration (~48695s seen in the dev log)
for every remote synth, which pinned the synth log's rtf to 0.00 — making
"is TTS keeping up with real time?" unreadable.

Root cause: fish.audio streams the wav and can't know the final length up
front, so it writes a placeholder/oversized data-chunk size (0xFFFFFFFF) in the
header. wave.getnframes() trusts that placeholder → a huge, clip-independent
frame count. 48695.77 × 44100 ≈ 0xFFFFFFFF / 2 frames confirms it.

Fix: measure the PCM actually on disk (readframes stops at EOF) instead of
trusting the header's declared frame count, so the duration is real regardless of
what the header claims.

Verification

• Unit: a wav with the RIFF + data-chunk sizes overwritten to 0xFFFFFFFF still
  reports its true 2.0s (regression test).
• Real boundary: one real fish.audio synth now reports ~3.7s (was ~48695s),
  so rtf is meaningful again.
• Full suite: 232 passed, 12 deselected.

Scope

Pure observability fix (dev-log audio_s / rtf) — no runtime behavior change.
Independent of the cold-start PRs (#24/#25/#26); branches off main.

AI coding brief

• Original request: While analyzing the cold-start dev-log timings, the
  synth events showed audio_s=48695.77 rtf=0.00 on every clip — obviously
  wrong. User asked to fix this log bug first.
• Manual interventions: None on the fix itself; it fell out of the timing
  analysis the user asked for.
• Retro: The constant-across-clips value was the tell (a real duration would
  vary with text length) — a fast way to spot "reading a header field, not the
  data." Worth checking derived metrics against a couple of different inputs
  before trusting them in an analysis.

🤖 Generated with Claude Code