The CosmicFest streaming master completed in spec on every number I had thought
to check: I = -14.0 LUFS, LRA 7.5 from a source 10.6, true peak -1.0, duration
matching the source to the microsecond. It was also 192 kHz and 1.32 GB, from a
44.1 kHz source. 4.3x the size it should be, at a rate no platform wants.

ffmpeg's `loudnorm` oversamples 4x for true-peak detection and leaves the graph at
192 kHz without resampling back. Any chain ending in loudnorm inherits that. So
every chain here now ends `aresample=<source rate>:resampler=soxr`, with the rate
PROBED from the source rather than assumed, and `-ar` set on the output too.
Validated on the 90 s slice: 44100 Hz / 2 ch, duration exact, loudness unchanged.

The part worth writing down is that this is not a new bug. topic_postprod_mastering
has carried a section titled "Every master was 192 kHz (fixed c652d16)" since the
tidal-ears chain hit it, describing this precise failure and its cause. I wrote a
brand-new mastering tool without re-reading the omnibus that exists to prevent
exactly this, and reproduced it. The memory now records the recurrence and two
structural fixes rather than a note-to-self:

Put the resample in the chain BUILDER, so no future chain can omit it. And make
the in-spec gate assert FORMAT, not just loudness — sample rate and channel count
now sit in the pass/fail beside I/TP/LRA, and the output line prints them. A gate
checking only loudness is what certified a 4.3x-oversized master as ✓, and I found
it by ffprobing for an unrelated reason. That is luck, and luck is not a check.

Also fixed an indentation error I introduced while threading the rate through with
a scripted replacement whose search string matched inside deeper indentation than
intended — the kind of mistake that is instant to catch with a parse check and
invisible without one.

Cleaned up: the 192 kHz master deleted, the master unit restarted on the fixed
chain, and cosmic-finish re-queued behind it so the split cannot run against a
file that no longer exists.