[ealtun21]

Summary

Investigates whether the macOS e2e recording can be bit-equal to the offline render, as on Windows. It cannot, and the cause is in the product path, not only in the test capture. This PR documents the cause with measurements and tightens the macOS checks as far as the evidence allows.

Finding (spec section 14.4)

The Process Tap's leg of an aggregate device contains a sample-rate converter that no public option disables.

• In one aggregate and one IOProc buffer, the BlackHole sub-device channels are bit-exact (100 % of samples equal) and the tap channels are not (0 % equal).
• The tap leg is a linear-phase low-pass at about 0.85 of Nyquist with 1632 frames of extra delay. It scales with the sample rate (44.1, 48 and 96 kHz measured).
• No change in the response from: kAudioSubTapDriftCompensationKey off (read back from the composition), drift quality 0 or 127, tap kind (device-bound, global stereo, global mono), mute behaviour, or stacked.
• Setting the aggregate clock or main sub-device to the tapped device changes the filter to a steeper one, but it is still not exact and the in-band SNR is no better.
• The daemon adds no conversion: HalInputStream is in bypass in every run.
• Whole 512-frame buffers are lost after the tap in this VM, about 11 in 8 s. The daemon's output callback reported 0 underruns, 0 late callbacks and 0 us lock wait, and the tap IOProc saw no zero block, so the loss is in the VM's audio threads. The same-device topology and an all-or-nothing ring read did not change it (both dropped).

Changes

• The macOS recording is now judged on every channel (it was channel 0 only). The limits are per octave up to 0.33 of the sample rate: gain within 0.03 dB (was 0.3 dB) and in-band SNR of at least 50 dB (was coherence 0.95, about 13 dB).
• Measured over the full tier (2 and 16 channels, 44.1 to 192 kHz, all linear chains): gain below 0.001 dB and SNR 57 to 86 dB per octave.
• Fidelity (nonlinear: 0.012 dB, 39 to 49 dB) and the dithered all-effects chain (0.5 dB, 26 to 29 dB) get per-scenario limits through a new transfer_min_snr_db.
• Each run's notes now carry a "n of m segments bit-exact" line and the worst gain and SNR per octave across channels.
• contrib/e2e/macos/tapcap.m is the experiment tool used for the table in 14.4.
• The soak, THD+N and stress scenarios stay "not applicable" on macOS, with the reason updated. A trial run gave THD+N of -18 dB from the dropped buffers.

Verification

• make check is green.
• cargo xtask e2e --os macos --tier full on the macOS guest: every transfer check passes on all channels. The only failures are the existing latency-baseline gates (88.2, 96, 192 kHz and 44.1 kHz x16), which already failed the same way before this change. The baselines hold implausible negative values and were not touched.
• Not verified: real hardware (BlackHole only) and the GitHub arm64 runner.