fix(replay): Skip buffer-mode replay capture when rate-limited (DART-313)

[runningcode]

📜 Description

In buffer (on-error) session replay mode, the recorder intentionally keeps running while the SDK is rate-limited so the rolling buffer stays warm. However, when an error triggered captureReplay, the strategy still encoded the current segment and every buffered segment and handed the resulting envelopes to the transport — which then discarded them because of the active rate limit. That wasted CPU, disk I/O, and MediaMuxer file descriptors on replays that could never be sent.

This adds a guard at the top of BufferCaptureStrategy.captureReplay: if the Replay (or All) data category is rate-limited, we skip encoding and capturing entirely. This mirrors the guard session mode already applies via onRateLimitChanged/checkCanRecord. The buffer keeps rolling cheaply in the background and captures normally once the rate limit expires.

💡 Motivation and Context

Follow-up to the session replay resource-leak work in #5583 and #5607. Those fixed the MediaMuxer FD leak during encoding; this closes the remaining item called out in getsentry/sentry-dart#3528 (DART-313): while rate-limited, the Android SDK kept creating and encoding segments that were only going to be discarded.

💚 How did you test it?

Added a unit test (captureReplay does nothing when rate-limited) asserting that, even with a buffered segment present, no segment is sent to the transport and no replayId is written to the scope while rate-limited.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Optionally extend the same guard to the pause and onConfigurationChanged encode paths in buffer mode if that churn proves significant.

[linear-code]

DART-313

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.49.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	317.33 ms	342.69 ms	25.36 ms
Size	0 B	0 B	0 B

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
eb95ded	317.51 ms	369.08 ms	51.57 ms
2124a46	319.19 ms	415.04 ms	95.85 ms
c3ee041	310.64 ms	361.90 ms	51.26 ms
dcc6bbf	382.58 ms	462.13 ms	79.54 ms
7a19fee	315.46 ms	368.62 ms	53.16 ms
9054d65	330.94 ms	403.24 ms	72.30 ms
d500866	326.13 ms	378.70 ms	52.58 ms
ad8da22	365.86 ms	427.00 ms	61.14 ms
ed33deb	337.52 ms	484.06 ms	146.54 ms
d15471f	310.26 ms	377.04 ms	66.78 ms

App size

Revision	Plain	With Sentry	Diff
eb95ded	0 B	0 B	0 B
2124a46	1.58 MiB	2.12 MiB	551.51 KiB
c3ee041	0 B	0 B	0 B
dcc6bbf	1.58 MiB	2.12 MiB	553.10 KiB
7a19fee	0 B	0 B	0 B
9054d65	1.58 MiB	2.29 MiB	723.38 KiB
d500866	0 B	0 B	0 B
ad8da22	1.58 MiB	2.29 MiB	719.83 KiB
ed33deb	1.58 MiB	2.13 MiB	559.52 KiB
d15471f	1.58 MiB	2.13 MiB	559.54 KiB