fix(android): keep a trimmed WAV extraction exact, release 2.22.0

[hm21]

Description

A trimmed WAV extraction on Android came out short and shifted: ~70 ms for AAC-LC, over 100 ms for HE-AAC. The AAC decoder drops the encoder delay and padding counted from wherever it starts, so after a seek it threw away real audio instead of the priming.

The decoder now keeps priming and padding, and the range is cut from its output on the audio's own timeline. Both ways an MP4 can declare the delay are handled: iTunes metadata (first sample at 0) and an edit list (first sample before 0, as ffmpeg writes it).

Measured on a Galaxy S942B with clips whose bursts start at exactly 0.6 s and 1.2 s:

	before	after
AAC-LC, trim 0.5–1.5 s	932 ms, bursts 11 ms early	1000 ms, exact
HE-AAC v1/v2, trim 0.5–1.5 s	885 ms, bursts 11 ms early	1000 ms, exact
ffmpeg AAC, trim 0.5–1.5 s	975 ms, bursts 34 ms early	1000 ms, exact
ffmpeg AAC, full	2020 ms	2000 ms

macOS gives the same numbers. MP3 trims now have the exact length but are still ~52 ms early: after a seek the MP3 decoder discards two frames and stamps its output by sample count. That was already the case before (75 ms early and short).

Found while testing #225, whose new HE-AAC test fails on Android without this.

Tests

• New extractAudio to WAV keeps a trimmed range in place (two ~5 KB AAC clips); fails on stable, passes on Android and macOS.
• Galaxy: audio_extract, audio_track_trim, audio_fade, audio_merge, clip_volume_custom_audio, layered_composition_audio, all green; JVM unit tests green.

Type of Change

• 🛠️ Bug fix (non-breaking change which fixes an issue)