[ZogStriP]

Previously, hls.js started loading levels and fragments as soon as the manifest was parsed, so every video using hls.js buffered up to 30 seconds of video as soon as it rendered, even if nobody played it and the Mux poster already served as the preview.

This change sets autoStartLoad: false so only the master playlist is fetched up front, and calls startLoad() on the first play event. An early play is safe because hls.js defers a startLoad() that arrives before the manifest is parsed. The listener uses the render's abort signal, so a replaced player never starts loading a destroyed instance.

It also enables capLevelToPlayerSize on that first play, so hls.js doesn't pick a rendition larger than the player. Capping polls the player size every second, so enabling it up front would run that timer for every video on the page, played or not.

The native HLS path, used where hls.js isn't supported, is unchanged.

The trade-off is a short delay on the first play, and no duration in the player controls until then.

Part of a stack of PRs, to be merged in order:

1. FIX: Show a poster for Mux videos and play them inline on mobile #103
2. FIX: Update the right posts when a Mux video becomes ready #104
3. DEV: Simplify the webhook, playback lookup and their specs #105
4. PERF: Cut per-post queries and table scans for post videos #106
5. FIX: Render each video in a post with its own status #107
6. DEV: Simplify video rendering and consolidate its tests #108
7. UX: Use sentence case for video strings and fix the preview placeholder #109
8. FIX: Show video changes in posts without reloading the topic #110
9. PERF: Load video streams only once playback starts #111 👈 this PR
10. DEV: Move video rendering into a module #112
11. FIX: Restore video embeds in chat messages #113