📜 Description

The MediaMuxer is opened eagerly in SimpleVideoEncoder's constructor, but its release() was only reachable on paths that assume start() succeeded. Two cases leaked it when the encoder failed to start:

• ReplayCache.createVideoOf constructed the encoder and called start() in a single expression (SimpleVideoEncoder(...).also { it.start() }). If start() threw, the assignment to the encoder field never happened, so the only caller of release() could never run.
• SimpleVideoEncoder.release() released the muxer as the last statement of the try block, after draining and stopping the codec. Draining a codec that never started throws, which jumped to the catch and skipped the muxer release.

The fix releases the encoder if start() throws (then rethrows), and always releases the muxer from a finally block so it is freed even when draining/stopping the codec fails.

💡 Motivation and Context

This surfaced as a CloseGuard "A resource was acquired at attached stack trace but never released" warning pointing at the MediaMuxer allocation in SimpleMp4FrameMuxer. It is a real resource leak on devices where the encoder fails to start, not just a test artifact. Complements #5583, which closed the no-frames and never-started paths.

💚 How did you test it?

Added a regression test (ReplayCacheTest.releases the muxer when the encoder fails to start) that forces start() to fail via the test MediaCodec shadow and asserts, through ShadowCloseGuard.getErrors(), that no MediaMuxer leak is reported. Verified the test fails without the fix (with the exact Explicit termination method 'release' not called error) and passes with it. The full ReplayCacheTest suite is green.

📝 Checklist

• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

None.