Defer SfxEngine AudioContext creation so app open doesn't register a new system audio client

[ryanmagoon]

Problem

Since #181, SfxEngine creates its AudioContext eagerly at module load (apps/desktop/src/renderer/lib/audio/SfxEngine.ts). This means merely opening GameLord registers a brand-new CoreAudio client (the Chromium audio helper) with the OS before the user has interacted at all — even when sound effects are disabled in preferences.

On systems running audio-routing utilities that interpose new audio clients (observed with SoundSource 5.9.0's ARK HAL driver on a macOS 27 beta), this registration triggers a live rebuild of the system audio routing — per-client DSP init plus on-the-fly aggregate device activation (HALS_Client::AddMuter, HALS_Device::Activate in the coreaudiod log) — which audibly bit-crushed all running system audio (Apple Music, YouTube) for ~5–10 s, and once degenerated into a loud buzz. A/B testing confirmed: full app boot with the utility running → interposition + crunch at T+2 s; with the utility quit → zero interposition events and clean audio.

The third-party driver owns the mangling, but GameLord controls the trigger surface: an app that opens an output stream at boot, with nothing to play, pays this cost on every launch for affected users.

Proposal

Create the AudioContext lazily instead of at module load, e.g. on the first user interaction (any pointerdown/keydown warms it up) rather than the first play() call. This keeps the ~500 ms OS audio-subsystem init off the critical path of the first audible sound (the regression #181 fixed) while not registering an audio client during boot.

Also skip creating the context entirely while sfx-enabled is false — today the constructor creates and connects it even when the user has sounds disabled.

Acceptance criteria

• Opening the app produces no CoreAudio client registration until the user interacts (verify with /usr/bin/log stream --predicate 'process == "coreaudiod"' — no AddMuter/Activate events attributable to com.gamelord.app.helper at boot).
• First sound-effect playback still has no audible latency hitch (the fix: eliminate UI hitch on first sound effect playback #181 regression stays fixed).
• With sound effects disabled, no AudioContext exists at all.

Diagnosis context

Full write-up of the investigation lives in the diagnostic session from July 1, 2026 (CoreAudio watcher + audio canary harness; device-level sample-rate/overload/format hypotheses ruled out with instrumentation before the interposition mechanism was found in the coreaudiod logs).