[Bug]: [P3] Audio first-cue latency: arm the first sfx on Tone unlock; jingle-bake gated on a mid-Android measurement

From the party consultation on audio baking (2026-07-13), folded from the deferral inbox by #545. The consultation's one concrete deliverable plus its gated sibling; no audio-latency row existed. (The other two threads are settled: baking the ambient score to WAV was rejected unconditionally, and sampled stems into the mixer is a separate future exploration.)

• First-gesture silence (the concrete deliverable, ready). ToneAudioEngine.sfx() no-ops until this.started is true, so the very first click or build cue, fired before the Tone graph is unlocked, is silent. This is a latent bug independent of any baking decision: the graph should queue or arm the first cue on unlock. Fix on its own small PR.
• Jingle-bake (gated, do not build on spec). Baking the ~6 short one-shot cues (build-complete, star-up, error, etc.) via Tone.Offline into an AudioBuffer, or shipping small compressed Opus/Ogg assets, so a cue fires from a decoded buffer instead of spinning up synth voices. The ONLY justification is first-cue latency on a mid Android device, and the gate is a real measurement of that latency, which cannot be taken in the headless environment. If the measurement comes back fine, ship nothing. If baked, add the assets to Workbox globPatterns (currently no audio type) and re-check the precache budget.

Audio/tooling. P3: the silence is a minor first-cue miss; the bake is gated on a measurement.

Tracked as backlog row audio-first-cue-latency; folded from the deferral inbox by #545.

Start at the ToneAudioEngine.sfx() entry point and trace the this.started and Tone unlock flow for the first click or build cue. Done means the first cue is no longer silently dropped before unlock; leave the jingle-bake sibling gated on a real mid-Android latency measurement.