fix(subtitle): decrypt LL-HLS VTT AES parts per-part

[hongjun-bae]

Problem

`SubtitleStreamController` only decrypts AES-encrypted VTT data at full-segment boundaries via `_handleFragmentLoadComplete`. When low-latency parts are in use, each part arrives through the progress callback (`_handleFragmentLoadProgress`), which the base class leaves as an empty no-op for subtitles. Concretely:

• `SubtitleStreamController` does not override `_handleFragmentLoadProgress`, so encrypted VTT parts never get decrypted on the fly.
• `_handleFragmentLoadComplete` takes `FragLoadedData` (full segment), not `PartsLoadedData`.
• `FragDecryptedData` has no `part` field, so a decrypted part cannot be routed downstream with its part anchor.

Net effect: encrypted VTT captions over LL-HLS either stay stuck in `FRAG_LOADING` for the tail parts of a partially-loaded segment, or — at best — only surface after a whole segment is assembled, losing the low-latency benefit.

#7626 covered the part-loading + segment-finding unification but the encrypted-VTT case was out of scope.

Changes

1. `SubtitleStreamController` overrides `_handleFragmentLoadProgress` to decrypt each encrypted VTT part as an independent AES-CBC stream using the segment-level IV, then emits `FRAG_DECRYPTED` with the part reference.
2. The full-segment path in `_handleFragmentLoadComplete` is reorganised to share a single `decryptPayload` helper with the part path (one decrypter lifecycle, one error path, single `shouldDecrypt` guard).
3. `FragDecryptedData` gains a `part: Part | null` field; `base-stream-controller` (init segment) and the full-segment subtitle path are updated to emit `part: null` so existing consumers compile.
4. A new `Decrypter` instance is constructed per call to avoid racing on the software-decrypter's shared remainder state when concurrent parts decrypt.

Test plan

• Added unit tests in `tests/unit/controller/subtitle-stream-controller.ts` for `_handleFragmentLoadProgress`: guard cases (no part / empty payload / not encrypted), success path (asserts `FRAG_DECRYPTED` is emitted with the part reference and the decrypted payload), and failure path (asserts `FRAG_DECRYPT_ERROR` is emitted with the part reference).
• Verified end-to-end against a live LL-HLS + AES-128 VTT stream: subtitles now appear on the part path without segment-duration latency, and the controller no longer stalls when subsequent ticks load the tail parts of a segment whose head parts were buffered earlier.
• `npm run type-check` and `npm run lint` clean.

[robwalch]

How is it possible to have concurrent part decryption?

Parts are loaded serially. This has never come up as an issue for encrypted audio or video parts handled in transmuxer.push.

A new Decrypter instance is constructed per call to avoid racing on the software-decrypter's shared remainder state when concurrent parts decrypt.

The remainder state may be shared, but software decryption is synchronous. If there is remainder data then you have other problems - you are not using it and you are not resetting/reinitializing the decrypter like the transmuxer is in other stream controllers on continuity change. I would expect that neither is the case, since you parts would need to be encrypted whole to be delivered before the segment is complete.

[hongjun-bae]

Confirmed — parts load serially (doFragPartsLoad recurses inside the prior part's .then(), and loadPart fires onProgress once per part), so there is no concurrent decryption and no shared-state race. Reverted to this.decrypter and removed the per-call instance and its rationale comment in 6a55fab.

On "encrypted whole": verified against the target stream — each part is a separate INDEPENDENT=YES resource with a static IV (no BYTERANGE), and the video renditions use byte-identical packaging and already decrypt per-part via transmuxer.push. Decrypting each part with the key's IV is correct here and mirrors the existing media-part path.

[robwalch]

Checking frag.encrypted is redundant.

[hongjun-bae]

Agreed — decryptdata.key && decryptdata.iv && isFullSegmentEncryption(method) already implies the fragment is encrypted, so the frag.encrypted check is redundant. Removed in 6a55fab.

[robwalch]

Promise.finally is not available in the minimum browser requirements.

Use this.decrypter. The base controller cleans up on destroy.

[hongjun-bae]

Both addressed in 6a55fab. Promise.prototype.finally is ES2018 — below the documented minimum (Chrome 39+/Safari 9+) and the es2015 lib target — so I dropped it and reverted to this.decrypter, letting the base controller's destroy() handle teardown.