filters.c uses SMUL64R (direct 64x64->64) on desktop and ESP32S3.

[dpwe]

In #950, @rt-rtos showed a case where the 32x32 mult wasn't providing enough resolution, and supplied a fix using int64_t multiplication. This turns out to be faster than the int32_t multiplication + gymnastics we had been using on ESP32, so I adopted it for all the filtering.

The change leads to numerical differences in all the filter calculations, but they are improvements, particularly the removal of block-floating-point shift-change artifacts.

The block-floating-point path is retained for non-ESP32 MCUs. I need to test performance on RP2040 and RP2350.

[github-actions]

🎛️ AMY HW CI (AMYboard bench)

Flashed this PR's AMY (LoadTestChord: 6-voice Juno patch=1, one held note every 2 s) onto the physical AMYboard and measured the smoothed render load as the chord grows — back-to-back with the same sketch built at the PR's merge base, so Δ is this PR's own cost.

✅ PASS — the bench ran the test to completion.

notes held	main @ 2291ff8	this PR	Δ
1	1472	1386	-86
2	1659	1550	-109
3	2332	2136	-196
4	2545	2329	-216
5	3278	2975	-303
6	3499	3169	-330

Full chord settled render μs: 3171 (was 3500, Δ -9.4%) (peak 3180, 39 samples)

⬇️ Artifacts: serial log · load trace · report

_{Self-hosted bench (amyboardci). FAIL means only that the test could not run — the load values are informational, with no threshold and no audio compare. See tools/arduino_loadsweep/.}

[bwhitman]

⛓️ tulipcc integration PR opened

This merge was pinned into tulipcc for full-system CI: shorepine/tulipcc#1210

Test it there and merge that PR to move tulipcc onto this AMY.