fix(silence): keep negative silence_start intervals as split boundaries

[seonghobae]

Why

ffmpeg's silencedetect filter back-dates silence_start by the detection window (d), so a recording that begins in silence reports a slightly negative silence_start (e.g. -0.00816327) — a well-known ffmpeg quirk. The parser regex only accepted [0-9]+, so the negative value failed to match. Because .search found no start, current_start stayed None, the following silence_end was orphaned, and the entire silence interval was silently dropped.

When such a head silence extends past the segment midpoint, it is the ideal split boundary. Dropping it forced build_segments to fall back to a hard split at window_end - epsilon, cutting in the middle of audio instead of inside the silence.

Reproduced before the fix:

parse_silencedetect_intervals("silence_start: -0.008 / silence_end: 150.5") -> []   # interval lost
build_segments(300s, max=200s, ...) -> split at 199.999 (mid-audio) instead of 150.5

What

Allow an optional leading sign (-?) in the numeric value of the silence_start / silence_end regexes. Smallest safe diff; no behavior change for the existing non-negative cases.

Tests

• test_parse_silencedetect_intervals_keeps_negative_start_at_recording_head — negative silence_start is now parsed into a complete interval (fails on old code, returns []).
• test_negative_start_silence_still_drives_split_point — build_segments now splits at the silence boundary (150.5s) rather than a mid-audio hard split.

Gates: coverage 100% on media_shrinker.py, interrogate 100%, full suite green apart from the 5 pre-existing macOS-only os.listxattr baseline errors.

🤖 Generated with Claude Code