fix(hls): preserve caller isolation in persistent HTTP reads

[brandomoore]

Summary

Restore Swift 6.4 compilation of persistent HTTP body reads without making mutable chunked framing or progress closures Sendable.

The 7.40.0 source fails in a consuming tvOS application with sending 'current' risks causing data races in Body.next(). Adding isolation only to readChunk reveals the same error for progress when it reaches nextBytes.

What changed

• Inherit caller isolation in both readChunk and nextBytes with an isolated (any Actor)? = #isolation parameter. This keeps framing and progress callbacks in the caller's isolation domain across both awaits.
• Keep the existing locking, cancellation handlers, socket deadlines, and connection-reuse checks.
• Add a chunked-response regression that carries framing across repeated cancellation-handler reads and uses a progress closure capturing the consumer's received-byte count.
• Document the isolation contract and add an Unreleased changelog entry. There are no public API changes or unchecked Sendable conformances.

Test plan

• Device / OS: Apple TV 4K (3rd generation) simulator, tvOS 26.5; Xcode 27.0, Swift 6.4.
• Source media (container / video codec + profile / audio / HDR-DV): no media playback; the existing loopback HTTP fixture serves a deterministic 5,000-byte chunked response.
• Result: all 20 Issue732PersistentHTTP1Tests passed with no skips, including testChunkedReadsKeepFramingAcrossCancellationHandlers. The new test verifies the complete payload and reusable final framing.
• A consuming Plozz integration containing the same two-method fix also completed a signed, optimized Debug tvOS device build. Its engine integration bundle passed 173 tests, with five existing platform-dependent skips.
• Real-media physical-device playback has not been evaluated by this transport regression.

Checklist

• CHANGELOG.md updated
• Commit messages follow Conventional Commits (feat(...), fix(...), chore(...))
• The fix lives in the engine, not in a host-side workaround
• Public API changes are intentional and documented (none)