Electrobun GPUWindow: add audio parity for native render mode

[devallibus]

Problem

The current Electrobun GpuWindow path does not have audio parity with the browser or BrowserWindow path. In practice, examples using the GPU-native render path cannot rely on the existing webtau/audio helpers and have to drop audio feedback entirely or invent runtime-specific workarounds.

This leaves a noticeable capability hole for any game that depends on immediate sound feedback for hits, warnings, UI actions, or ambient state.

Why this matters

• Audio is part of gameplay feedback, not a nice-to-have.
• The portability story is weaker when render-mode changes also remove basic sound support.
• Every GPU-native example will otherwise re-solve the same adapter problem.

Suggested scope

• Define a minimal audio abstraction that can be satisfied in both DOM and non-DOM runtime paths.
• Keep parity focused on practical game needs first: resume/unlock, mute, master volume, and lightweight sound playback.
• Be explicit about what is and is not promised in GPU-native mode.

Candidate directions

• Extend webtau/audio behind an adapter boundary so native runtimes can provide an implementation
• Ship a minimal Electrobun-native audio adapter for the supported GPU path
• Provide a capability check plus fallback behavior when the runtime cannot satisfy the full surface

Acceptance criteria

• GPU-native examples can play basic gameplay/UI audio without app-specific hacks.
• The supported surface and limitations are documented.
• The API shape remains usable from shared gameplay code.

Related

• [P2] Publish BrowserWindow vs GPUWindow capability matrix #105
• [Design] RenderAdapter interface for non-DOM rendering paths #117