5.9.0

Handing an HLS playlist URL to the generic live path no longer hangs forever; it now fails closed with a typed error. Minor release (adds one public API symbol).

Fixed

• load(url: m3u8, options: LoadOptions(isLive: true)) without nativeRemoteHLS no longer hangs at .loading with no error. That call bypasses the documented HLS entry points (LoadOptions.nativeRemoteHLS and HLSLiveIngestReader) and routes the playlist URL onto the raw-byte live reader. A live origin serves the finite #EXTM3U body at HTTP 200 and closes the connection; the endless-feed reader read that as a dropped live stream and reconnected, re-fetching the same body forever. The reconnects looked productive (a full body at 200, and every find_stream_info probe seek reset the unproductive-reconnect streak), so the reconnect give-up counters (#71) never tripped, avformat_open_input never returned, and no terminal state was reached (reporter observed 262 reconnect cycles over 5.75 minutes).

  The raw-byte reader now inspects the first bytes of a live source and fails closed when they are an HLS playlist tag (#EXTM3U, tolerating a UTF-8 BOM and leading whitespace), before the reconnect loop is ever entered. A raw media container never opens with # (TS syncs on 0x47; MP4 / MKV open with binary box / EBML markers), so the prefix is an unambiguous misroute. Reported by cmcpherson274 (#140).

Added

• AetherEngineError.hlsPlaylistOnRawLivePath. load() throws this typed, catchable error (with an actionable LocalizedError description) when an .m3u8 playlist is misrouted onto the raw live path, pointing the caller at LoadOptions.nativeRemoteHLS / HLSLiveIngestReader instead of looping silently.

Consumers on 5.8.9 should bump.