audiodynamics: reset() keeps the side-chain filter memory (33 LSB on the first block after reset)

[bdbarnett]

Found by the effects program's Phase 2 (2026-09-07): NoiseGate's evidence pack (audiocomponents/docs/effects/NoiseGate-evidence.md, the STATE row) measures 33 LSB on the first block after reset() with a silent source, and traces it to audioif_dynamics_reset leaving the side-chain filter memory in place (src/shared/audioif_dynamics.c:281-288). The class works around nothing; the pack records it as a cause below the class, committed as a test that goes red on the node. Expected: a reset node renders exact zero on silence from its first block. Additive fix in the audioif-own kernel; existing goldens must stay byte-identical (a reset only happens on the class's explicit call).

[bdbarnett]

Diagnosed, fixed, and parked on fix/dynamics-reset-clears-key-filters (085e602) rather than merged — it deviates from the vstaudio oracle, which is Brad's call and not a fixer's.

The defect is real, and worse than "33 LSB of residue"

A reset does not restore the node to its built state. Same settings, same material, both targets agreeing on both numbers:

fresh node, -60 dBFS tone under a -39.7 dB threshold : peak  0 LSB
the same node after a loud pass and reset()          : peak 32 LSB

The fresh-node control is the part that settles it: 0 LSB is what the gate is supposed to do with a tone 20 dB under its threshold, and a reset node passes it at full level because the stale high-pass state still says there is signal. It is the shared kernel, not a binding — the CPython target and desktop MicroPython give the same two numbers.

The fix

state_init and reset now go through one audioif_dynamics_clear_detector, so they cannot drift again: whatever a fresh build clears, a reset clears — the four side-chain filter states, the envelopes, the reported gain reduction, the peak history and the extras. Configuration is what survives (channel count, the lookahead storage the bindings own), and the lookahead contents still go, since that is audio in flight.

Why it is not merged: this is a deliberate deviation from the oracle

The issue expected "existing goldens must stay byte-identical (a reset only happens on the class's explicit call)". They do not, because two of the dynamics probes do call it. Measured:

probe	oracle-backed?	moves?
dynamics_probe.py	yes (vstaudio_oracle)	yes, 4 lines of 76
dynamics_options_probe.py	no	no
dynamics_extras_probe.py	no	no

The four lines, port against the oracle interpreter:

oracle                                        port with this change
dyn reset-gr -13.145889                       dyn reset-gr 0.000000
dyn reset-after 0 ... 131599 ... -6.717831    ... 131089 ... -6.718873
dyn reset-after 1 ... 128064 ... -10.425788   ... 128072 ... -10.426313
dyn reset-after 2 ... 131250 ... -13.145606   ... 131245 ... -13.145889

The transient is bounded. By the third block after the reset the port reads −13.145889 dB, which is the oracle's own pre-reset figure — so the steady state is identical and only the reset boundary differs. That is the whole size of the divergence.

What landing it needs beyond the C

1. The fixture cannot go on claiming to be the oracle's answer for those lines. verify_acceptance.py already solves this exact shape by keeping both — stdout enforced, circuitpython_stdout kept beside it so the size of the divergence stays reviewable rather than being quietly recaptured. verify_dsp's three oracle-backed probes have no such split, and --capture-old would rewrite all twenty from the oracle, which is the wrong hammer.
2. A fourth entry in docs/upstream-diff.md, beside the three deliberate biquad deviations.
3. audiocomponents' tripwire fires. test_reset_does_not_clear_the_key_filters_and_the_node_says_so was committed to go red on purpose if audioif ever clears them (NoiseGate's pack, §11). It stays green until AUDIOIF_PIN moves, and must be rewritten then to assert the new behaviour.

The question for Brad

Is "a reset means as if freshly built" worth diverging from the reference engine for, given the divergence is 4 lines of 76, confined to the blocks immediately after an explicit reset(), and converged by the third one? My reading is yes — the current behaviour makes a Tier 1 invariant unachievable for every dynamics class in audioeffects, and the fidelity being preserved is fidelity to a reset the original was never held to. But it changes what an oracle-backed gate means, so it is not mine to merge.