chore(mp3): leftovers from the fixed-vs-Helix work -- ledger path filter, huffman regression, upstreaming

Follow-up to #4138 and #4139, which are closed: the fixed-point decoder went from 3.99x Helix on an ESP32-C6 to 1.13x (#4140, #4150), and the shipping backend is now gated on a Callgrind, codegen and exact-operation baseline in codec_cpu_trend.json (#4148). Three items from those issues were never done and are collected here so they do not get lost.

1. codec_cpu_ledger.md does not exist but the workflow path-filters on it

.github/workflows/mp3_cpu_audit.yml lists codec_cpu_ledger.md in both its push and pull_request path filters (lines 19 and 34). The file has never existed; the real store is codec_cpu_trend.json. Either drop the two entries or create the file. Dropping is the simpler fix.

2. The fixed build's huffman stage is unexplained

Per-frame host medians recorded in agents/docs/mp3-decoder-performance.md:

stage	float	fixed
huffman	7,373 ns	12,134 ns

Huffman is integer work in both builds, so the fixed-point DSP does not explain a 1.6x difference there. Worth a Callgrind diff of L3_huffman between the two builds. It may be scratch-clearing or inlining differences rather than the decoder itself; ecb3d0588d already trimmed the scratch clear, so re-measure before assuming the number in the doc is current.

3. Nothing has gone upstream to lieff/minimp3

The fixed-point port is a FastLED fork. The findings that are of general interest and not FastLED-specific:

• mp3d_sat64 on every polyphase intermediate is redundant on conformant input (zero clamps across 82.5M calls on real music; all 4,609 clamps in the ISO suite come from l3-nonstandard-big-iscf).
• mp3d_mulshift_k for constant coefficients on targets without a single-register 64-bit product.
• The int64-heavy arithmetic is roughly free on x86-64 and 4x on a 32-bit RISC-V core, so host ratios understate the embedded gap.

Open an issue or PR against https://github.com/lieff/minimp3 pointing at the relevant commits.

Not in scope

• A Fast/HQ mode split. #4139 concluded it is unnecessary; the gap was saturation cost, not a precision trade.
• The 16-bit MAC path. Measured at 44.37 dB (#4108), below the ISO floor. Do not re-run.
• Chasing the remaining 1.13x to the 1.1x stretch goal. Fine to do, but it is optimisation work, not housekeeping, and bash mp3measure is the tool.

Generated with Claude Code

https://claude.ai/code/session_01XQyTuAVs4tK9pDcxAZVqVe