fix(cli): normalize the audio passage the clip plays

[user-github-me]

On an audio or audible video clip with data-playback-start, normalize-audio measures data-media-start (or zero) instead of the passage playback uses. On an 8s tone with a quiet intro and louder tail, a 2s clip starting at 4s gets a +7.6dB boost instead of the required −6.4dB reduction. A preferred offset of zero is also incorrectly overridden by the legacy attribute.

Use the existing playback offset reader for the shared loudness HTML scan: data-playback-start takes precedence, with invalid values falling back to data-media-start. Preserve validation of a legacy offset when selected and preserve source attributes when writing the gain.

Validation on current main:

• Six regressions fail before the fix; all 1,239 Studio-server tests and 26 CLI normalization tests pass.
• The rebuilt CLI and real FFmpeg select the correct passage for preferred-only, conflicting, zero, legacy, and invalid-preferred controls, including existing filename handling.
• Full workspace build, Studio-server build/typecheck, CLI build, repository lint, formatting, test reachability, commit hooks, and branch comment checks pass.

Original rendering validation: persisted compositions pass lint and strict browser check. Preferred-offset and equivalent legacy-offset SDR renders contain 10 frames over 2s with matching audio measurements. Each channel is −16.1 LUFS; the existing unity mono-to-stereo upmix measures −13.1 LUFS across both channels. Repeat --write is byte-stable, and reference matching preserves its reference.

[jrusso1020]

Confirmed: normalize-audio reads only data-media-start, while the render mixer and the runtime both prefer data-playback-start. So a clip trimmed with the newer attribute is measured over a different passage than the one that plays. Reusing the shared offset reader lines the two up, and the legacy attribute's validation still applies when it is the one selected. The new tests fail on main and pass here.

— Rames