audioif breaks every non-esp32 CMake port: _audioif.c is added with no port guard #15

What breaks if nobody fixes it: every non-esp32 CMake port fails to build the moment audioif is linked into cmods — and because cmods discovers usermods by what is sitting in it, that is every such build, for everyone, whether or not they wanted the audio pump.

Found building rp2 / RPI_PICO2 to compile-check an unrelated displayif change:

[100%] Building C object .../tinyusb/src/class/video/video_device.c.o
/home/brad/gh/pydevices/cmods/audioif/_audioif.c:56:10: fatal error: driver/i2s_std.h: No such file or directory
   56 | #include "driver/i2s_std.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:91: all] Error 2

driver/i2s_std.h is ESP-IDF. micropython.cmake adds both sources unconditionally once it finds audiodsp beside it:

target_sources(usermod_audiopump INTERFACE
    ${AUDIOPUMP_MOD_DIR}/_audioif.c
    ${AUDIOPUMP_MOD_DIR}/audiobusio.c
)

There is no port guard anywhere in that file. The header comment says "MicroPython CMake glue for the audio pump's platform driver (esp32)", so the intent is clear — it is the guard that is missing, not the intent.

This is the new-module drift trap, exactly as docs/agent-knowledge/workspace-craft.md describes it: "a module added to cmods for one port silently enters all the others' builds on their next run", and "the port a module is least for is the one nobody builds first". rp2 is that port. The same passage records usbif's UVC class compiling on esp32 and failing to link on every Makefile port, surfacing only because a different deck rebuilt through the aggregator — which is what happened here too.

The fix is a guard, and the shape is already in the tree. displayif handles the same problem by selecting sources per port. Something like an early return when the target is not esp32:

if(NOT (CONFIG_IDF_TARGET_ARCH_RISCV OR CONFIG_IDF_TARGET_ARCH_XTENSA))
    message(STATUS "audiopump: skipped -- not an esp32 target")
    return()
endif()

placed beside the existing audiodsp not found beside it return, which already establishes that skipping quietly is this file's convention. audiodsp itself stays portable and keeps building — it is only this repository's platform driver that is esp32-only, which is the whole point of the split.

Worth deciding rather than just guarding: whether audiobusio.c is esp32-only too, or whether it should still build (its header says it "opens a real I2S channel on esp32" and is something else elsewhere). If the second, the guard belongs around _audioif.c alone.

Not fixed here: audioif is not a tree this sitting holds for C changes, and the rp2 build was a means to an end rather than the work. The displayif change that found it compiled cleanly before this — mod_picodvi.c and picodvi_rp2350.c both built at 33%, so nothing above is about that PR (PyDevices/displayif#35).