Prepare Audio Subsystem for IDF5/Arduino 3.0, Harden S3 Support, add simulated beat.

[robertlipe]

Prepare Audio Subsystem for IDF5/Arduino 3.0, Harden S3 Support

It's my goal to land this before we switch, but to have the code in the
tree. It needs to be exercided on more hardware than I have right now
(it's fine on the analog mic of Mesmerizer) but it deserves widespread
testing.

I'm going to mar this as "pending" WIP, but go ahead and get it on
the group's repo so that those of us that care about such things will
have a centralized place for going so.

Gemini help me wrangle this code to "prove" it's right, so
I'll let it bigger rest of this.)

Summary

Refactoring the audio subsystem to break free from legacy technical debt,
preparing for the inevitable migration to ESP-IDF 5 and Arduino 3.0.

It tackles the brittleness of our audio input handling by properly
adhering to the "Five Modes" of input (M5Stack, Modern I2S, Legacy I2S,
Modern ADC, Legacy ADC) and ensuring that newer hardware (ESP32-S3)
doesn't panic when faced with older configuration patterns.

Key Changes:

• iModernization & Future-Proofing:

  • IDF 5 Readiness*: explicitly guards legacy ADC logic (which
    disappears in IDF 5) and prepares the "Modern" paths to be
    the primary citizens. Old paths will be deleted later.`

  • Refactored Initialization*:
    Cleans up the InitAudioInput logic to respect hardware
    capability (SOC_I2S_SUPPORTS_ADC) rather than just checking board
    defines, preventing invalid driver installs on S3. (Like the ones I use...)

• Hardware Stability (The "Five Modes"):

  • Formalizes the initialization order for our mixed fleet of hardware.
  • Crash Prevention*: Adds strict guards (INPUT_PIN < 0) to
    SampleAudio (_We should probably make THAT default in globals.h>
    to prevent LoadProhibited panics on devices that skip hardware
    init. This allows a device to exist in a "Simulated Audio Only"
    state without crashing the kernel.

• Feature: Runtime SimBeat:

  • Exposes simbeat [on|off] [bpm] in the CLI. Decouples "Audio
    Effects" from "Physical Audio Hardware," empowering developers
    to test reactive effects on the couch without a microphone or an audio source.

Context:

We are clearing the path to adopt standard ESP-IDF 5 practices while
maintaining support for our legacy fleet. This PR ensures that i2s_config_t
and adc_pattern usage remains safe as struct definitions evolve in newer
SDKs, moving us away from "hope-based compilation" to robust, capability-checked
configuration.

Description

Contributing requirements

• I read the contribution guidelines in CONTRIBUTING.md.
• I understand the BlinkenPerBit metric, and maximized it in this PR.
• I selected main as the target branch.
• All code herein is subjected to the license terms in COPYING.txt.

[rbergen]

My PR housekeeping question about this one is why you opened it as a draft? You know my opinion on these. ;)

[robertlipe]

I know. I also don't like that I can't really test all five paths because just don't have the hardware with me and I know you don't like things we haven't SEEN run.

Could we just submit it and fix on fail? Certainly wouldn't be the first on the audio path. (You know I'm not a fly by night on such things, either.)

Basically I needed this in two different branches of mine.. if you want me to keep this in my fork for longer, that's ok.

You can kick it into the field or out of the stadium. I'm flexible. I'm just recording my work somewhat publicly.

[rbergen]

I know this is a topic we have different perspectives on. However, particularly with something as brittle as audio has proven to be, I really don't want to take the "run with it and hope for the best" approach, this broadly. It may be weeks or months before a problem we'd introduce today pops up, at which time it's not unlikely we have completely forgotten this particular PR as the/a possible culprit.

So, I suggest we wait with merging this one until we do have the opportunity to test this more comprehensively than is now possible. I say "more comprehensively" because I don't mean we have to test every permutation, but a decent representation at least.

If I can contribute to that, then let me know how.

[robertlipe]

That's why it's marked as draft.

I want to get it some airtime for those able/willing to exercise it (which includes me, between branches of development).

It's not a merge candidate right now.

If this causes you stress (the opposite of my goal) then I'll pull this and quarantine it back into my trees where only I can/will see it. It's just another local change for me to carry around...