3.0.1: Persistent-reader window storage leak

Patch release fixing the second half of #31, the no-subtitle memory growth on large files.

Fixed

The persistent reader's sliding window (one long-lived forward-streaming connection, introduced in 2.x for #25) trimmed consumed bytes with Data.removeFirst. That only advances the slice's lower bound: the backing storage stays addressed from its origin, and the append-side growth keeps reallocating it to fit the slice's ever-increasing upper bound. The window's logical size held at ~20 MB while the single backing allocation grew with every byte ever streamed through the connection, ~14 MB/s on an 80 Mbps remux, until jetsam killed the app. Paused playback stops the stream, which made the footprint look stable while paused.

The trim now re-bases the window into fresh compact storage (subdata), and the same pattern is fixed in the sequential streaming reader. A standalone repro of the pattern (512 MB streamed through a 20 MB window) went from +513 MB phys_footprint to +9 MB flat, with the compaction copies costing ~0.1 s total.

Thanks @RomanLiberda for the memprobe output and the Instruments allocation stack that pinpointed this.

Full Changelog: 3.0.0...3.0.1