audioroute.Splitter has no deinit(), so a class that builds one cannot release it

[bdbarnett]

Stakes. Every audioeffects class that fans a source out for a wet/dry
mix builds an audioroute.Splitter, and none of them can release it. The
class gate's Tier 1 asks that deinit() release every node the class built;
on Compressor the answer is 5 of 6, every time, and the sixth is the
Splitter. A host that builds and tears down effects in a session leaks one
Splitter — 34 KB by the Phase 2 cost table's RAM column — per instance.

What the surface is. audioroute.Splitter's Python surface is tap
alone: no deinit, no reset. Its taps carry both, and a tap's
reset_buffer is deliberately a no-op ("the cursors belong to the Splitter
and the other taps are still reading from them",
audioif/src/audioroute/SplitterTap.c:47-55), which is correct — the ring
belongs to the Splitter, so only the Splitter can free it.

Measured, audiocomponents at AUDIOIF_PIN 2f6cbc3, 2026-09-07:

$ .venv/bin/python tools/compressor_evidence.py deinit
  node                 owned for deinit   received the call   _deinited
  0 Splitter           no (no deinit)     no                  n/a
  1 SplitterTap        yes                yes                 True
  ...
  5 of 6 nodes owned, 5 of 5 calls received

Compressor owns the Splitter deinit=False on purpose, because calling a
deinit it does not have would be a build failure; the evidence pack
records it as a palette gap rather than a class choice
(audiocomponents/docs/effects/Compressor-evidence.md §2, §11).

Ask. audioroute.Splitter gets deinit(), freeing the ring, with the
usual deinitialised guard on tap() afterwards. Every Splitter-headed class
in audioeffects then closes this Tier 1 row.

[bdbarnett]

Correcting the record: this was closed on two of three targets, not three.

The commit closing it described tests/parity/deinit_surface_probe.py as "running unchanged on all three targets". The probe does run on all three. I only ran it on two — the CPython target and desktop MicroPython — and said so as though I had run three. Running it on the patched CircuitPython build, once that build existed later the same day, fails:

$ MICROPYPATH=. .../build-coverage/micropython tests/parity/deinit_surface_probe.py
  audiobiquad.Biquad has no deinit()
  audiodynamics.Dynamics has no deinit()
  audioroute.Splitter has no deinit()
  ...
exit=1

Measured: 0 of 13 type files under src/circuitpython_spike/shared-bindings/ contain MP_QSTR_deinit. audioif keeps a second, hand-written binding per module for CircuitPython, and it never received this work.

The MicroPython and CPython halves stand and are gated. The CircuitPython half is tracked in audioif#75, together with the two other instances of the same lag found the same day and the check that should have caught all three. Leaving this issue closed and the remaining work in #75 rather than reopening four issues for one cause.