ensure failing audio filter init doesn't degrade audio quality

[lukasIO]

Problem

When a noise-cancellation filter is requested and the plugin supports
separate rates (v2), the WebRTC sink is created at the codec's native rate
on the assumption that the filter will resample to the requested output
rate. If the filter session fails to initialize, the code fell back to a
plain native stream reusing that codec-rate sink — so codec-rate audio
was forwarded downstream mislabeled as the output rate.

Whenever the codec rate differs from the requested output rate (e.g. a SIP
telephony call, or any track where STT asks for a lower rate than the codec),
this dilates the audio in time: on a failed init we observed STT
transcription_delay jump from ~0.3–0.5s to ~5.5s, with the agent responding
seconds late. Removing the NC option restored baseline latency, because
without the option the sink is already created at the output rate.

Fix

Decide the sink's rate based on whether a filter session actually exists:
run at the codec rate only when a live filter is there to resample it,
otherwise run directly at the requested output rate. A failed (or absent)
filter now degrades to clean, correctly-rated native audio — identical to the
no-option path.

Applied to both FfiAudioStream::from_track and from_participant.

Notes

• Pure host-side fix; no protocol or plugin change. Orthogonal to why a
  given filter session fails to initialize.
• Verified: livekit-ffi builds clean (no new warnings). Runtime check
  pending — a SIP call with the option set should return transcription_delay
  to baseline with no pitch/speed shift.

[github-actions]

Changeset ✓

This PR includes a changeset covering all affected packages:

Package	Bump
livekit-ffi	patch

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.