SDK keeps capture active while uploading after Stop #3190

Description

The recording SDK keeps camera, microphone, display and mixed audio tracks live after Stop while video creation and multipart upload are pending. Encoding has finished, so capture should be released without waiting for the network.

This affects the exported CapRecorder.stop() and the React hook that forwards to it. A slow or stalled upload prolongs active capture until upload succeeds or rejects.

Reproduction

1. Start an SDK camera recording with microphone enabled.
2. Hold or delay the /videos/create response through a network fixture.
3. Call recorder.stop() and leave that response pending.
4. Inspect the acquired tracks during the SDK's uploading phase.

Expected: the capture tracks are ended once encoding has stopped, while the recording uploads.

Actual: both camera and microphone tracks remain live at 150 ms and one second into the held request. The same result occurs when stopping a paused recording and with screen, system audio and microphone capture. A delayed request that later returns HTTP 503 also keeps capture live until rejection.

Additional Context

• Baseline: 2169a6ae96fd6dc2938e575818479aa702a5cf6e; affected SDK source also matches the original reproduction at 08a15f27209d5797ec502bb7a80cc3a90a563b6b.
• Environment: Linux, Bun 1.4.4, native Chromium recording APIs with synthetic streams and fixture HTTP.
• Three actual-module regressions fail on baseline. Existing 29 SDK tests pass.
• Ten native browser runs reproduce the before/after behavior. All eight successful WebMs retain every emitted chunk and decode as VP9/Opus.
• Physical devices, OS privacy indicators, Firefox/Safari and authenticated cloud storage were not exercised.

stop() already waits for final encoder data, but releases streams only through cleanup after upload. The existing stream owner can release capture at that stop boundary while retaining the chunks. This is separate from #2970, where the camera source had already ended before saving.