Share the native audio runtime across effects

[tontontimiro]

Why the change

Replace three copies of the native audio runtime with one shared implementation so fixes cannot drift between audio effects.

Special things to note

• Local checks passed: 1,416/1,416 Linux tests in Docker using the gate's selection and judgment helpers, repo gate 46/46, four macOS audio tests, and all seven effect combinations on both platforms. AudioToolbox and ALSA null output passed open/write/close. Open Code Review finished with zero new findings; three initial findings concern unchanged ALSA code, and I reviewed the unsupported Bend/Markdown files manually.
• All 16 runtime benchmarks emit byte-identical C and JS before and after; all 48 sequential CPU, parallel CPU and Metal runs match the expected outputs. Three-sample median compiler timings average +0.7% across benchmarks, with a worst case of +11.3%; the worst of five checker timings was +14.1%. Fixed nine-sample repeats of those two worst cases measured -1.0% and +0.1%, respectively, so the initial increases did not reproduce.
• These performance measurements ran natively on an M5 Pro after the Docker suite finished, against the baseline on the same machine, not against M4 pins. The official test/perf gates still need the mini cluster; SSH host cluster is unavailable here. No compiler, kernel, Lean, JS, gate limits or pins changed.

Change outline

The native sources shrink from 545 to 220 lines; including 42 lines of regression tests, the full PR removes 283 lines and 2,908 ttok (78 added, 361 removed).

 Base.Audio.{open, write, close}
-  audio_open.c  -> ring + platform backends + open
-  audio_write.c -> ring + platform backends + write
-  audio_close.c -> ring + platform backends + close
+  audio.c -> existing eff_src realpath deduplication -> one shared runtime
+    CID_AUDIO_OPEN  defined -> unchanged open body + registration
+    CID_AUDIO_WRITE defined -> unchanged write body + registration
+    CID_AUDIO_CLOSE defined -> unchanged close body + registration

The guards cover whole effect entries, so a program using only one effect never needs IDs for the other two; the three new standalone-effect tests cover that boundary. The shared ring/platform code and all effect bodies match the originals byte-for-byte.

[VictorTaelin]

Merged into 2.0.25 under your authorship, thank you: one audio.c, the ring emitted once, and a program that imports one effect builds alone. We preferred this over #949 because it uses the dedup the compiler already has and adds no mechanism.

Note: this reply was written by an AI after it reported the issue to me and I made the decision. If anything here is wrong, reply and I will review it myself.