Bump DspTap to 0eb09fa (+ SampleRateTap test pin); re-record icount; correct the construction-share claim

[tap]

What this changes

• Pins. submodules/dsptap moves 28a34a1 → 0eb09fa, which includes kaiser: share the Kaiser window's Bessel series (bit-identical, −32% on M33) DspTap#38. The test-only submodules/sampleratetap moves 5315689 → 2b4dff1 in step.
• Baselines. bench/baselines.json is re-recorded on M33, M55 and Hexagon.
• PLAN.md. A new M7e ledger entry, plus a correction to M7c's claim that construction is "<0.3% of every workload".

Why

DspTap#38 computes the Kaiser window's Bessel series once, for half the taps, and mirrors it. The coefficients are bit-identical and the design is cheaper. RatioTap designs its prototype at construction for every profile (phase_table.h → design_prototype), so every ratchet workload's construction got cheaper:

• Ten of ten M33 scenarios and eight of ten Hexagon scenarios left the two-sided ±3 % gate. The largest move is M33 down_q15_eco, −28.9 %.
• M55 moved −1.0…−2.1 % (inside the gate), and I re-recorded it too to keep the gate tight.

The SampleRateTap pin moves too because of an invariant. RatioTap compiles SampleRateTap's headers against its own tap::dsp, and that relies on both repos pinning the identical DspTap tree (see the comment in CMakeLists.txt). SampleRateTap main now pins 0eb09fa. There are no header changes in 5315689..2b4dff1.

Verification

• Construction only. The deltas are constant per profile and direction, and identical across float/Q15/Q31: down economy is −70.7 M on M33 in all three formats. The coefficients are bit-identical (DspTap#38's fingerprints on M33 and x86 GCC/clang). The scipy reference vectors and the cross-validation floors pass unmoved.

• Host. 78/78 tests pass under GCC 13 and clang 18 with TAP_RATIO_WERROR=ON; scripts/tidy.sh is clean.

• Ratchet. It flagged the moves above before the update. After icount.py --update it passes on all three targets, built with CI's configure line, the repo's plugin (same pinned header SHA), arm-none-eabi-gcc 13.2.1, hexagon-clang 19.1.5 and plugin-enabled qemu-hexagon 8.2.2. This PR's ratchet job is the CI cross-check.

• Construction share. A scratch program builds only each scenario's converter (no audio) and is counted on every target:

  Target	float	Q31	Q15
  M55	3–4 %	3 %	4–5 %
  Hexagon	5–6 %	33–37 %	32–37 %
  M33	6–8 %	42–45 %	55–63 % (67–74 % before this bump)

• Not run locally. The bare-metal and Hexagon test legs, left to CI.

Notes for the reviewer

• Submodule pins moved: DspTap 28a34a1 → 0eb09fa (brings DspTap's FFT stages and math.h, unused here); SampleRateTap 5315689 → 2b4dff1 (test-only).
• Construction dominates the M33 fixed-point baselines. A real hot-path regression there is diluted about 2–3× before the ±3 % gate sees it. The historical per-lever M33 percentages in PLAN §7 were measured through the same dilution, so I left them alone and say so in M7e.
• Two possible remedies: a construct-only ratchet scenario, or SampleRateTap's two-length method (steady state = 4 s − 2 s). Either is a separate PR if wanted.
• Coefficient baking. M7c deferred baking coefficients into flash on the <0.3 % premise. It's still deferred, but the premise is now stated correctly.

🤖 Generated with Claude Code

https://claude.ai/code/session_01G3HxzEGiZp7jStoMuYNuBK

---

Generated by Claude Code