…313)

In buffer (on-error) mode the recorder keeps running while rate-limited so
the rolling buffer stays warm, but capturing on an error still encoded the
current and buffered segments and handed them to the transport, which then
dropped them. That wasted CPU, I/O, and MediaMuxer file descriptors on
envelopes that could never be sent.

Bail out of BufferCaptureStrategy.captureReplay when the Replay (or All)
category is rate-limited, mirroring the guard session mode already applies.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…imited (DART-313)

Skipping the encode when rate-limited meant the segments never reached the
transport, so RateLimiter.filter never recorded them as lost. Replay drops in
buffer mode silently vanished from client reports.

Record a RATELIMIT_BACKOFF lost event for the Replay category at the bail-out,
and move the rate-limit check below the sampling and isTerminating guards so we
only report replays that would genuinely have been sent — a replay dropped by
onErrorSampleRate is not a rate-limit loss, and a terminating one is deferred to
the next launch rather than lost.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Bailing out of BufferCaptureStrategy.captureReplay while rate-limited left
isTerminating unset, so ReplayIntegration's unconditional convert() still
swapped in a SessionCaptureStrategy. That discarded the rolling buffer, and
the next recorded frame then hit checkCanRecord(), which pauses session mode
when rate-limited and encodes a segment on the way out - exactly the work the
bail-out was meant to avoid. It also left recording paused for the rest of the
rate-limit window, contradicting onRateLimitChanged, which deliberately keeps
buffer mode running.

Stay in buffer mode while rate-limited so the buffer keeps rolling and the
next error after the limit expires can send a complete replay.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>