fix(01-11): activation-aware resume grace; iframe stage context created at mount

Found while proving the unlock under a strict autoplay policy:

- playBuffer's bounded resume() used one fixed grace. Under load the audio sink
can take seconds to start after a legitimate in-gesture unlock (0.7-5 s
measured on the headless fleet), and a fixed 2 s produced a false "audio is
blocked" error. Nothing separates "blocked" from "slow" except whether the
document has ever been activated, so the grace now follows
navigator.userActivation.hasBeenActive: 2 s when it never was (nothing can
unblock it - say so quickly), 8 s once it has (the resume is legitimate and
only waiting for the sink). Unknown (older browsers) is treated as activated.
- stage.html creates its AudioContext at 'avatar:mount', as the inline
transport does at boot, so audioState reads 'suspended' rather than 'none'
before the first gesture under the iframe transport and the strict-policy
precondition holds under both transports.

avatar/audio-queue.js

@@ -13,8 +13,20 @@ const START_LEAD = 0.05; // a small lead so the first viseme is not already late
 // blocked. Chromium keeps the resume() promise PENDING - neither resolved nor rejected -
 // while its autoplay policy blocks the context, so an unbounded await would hang the turn
 // forever with the status stuck on "speaking..."; the bound is what makes the refusal in
-// playBuffer reachable. A context that is allowed to run resumes in a few milliseconds.
-const RESUME_GRACE_MS = 1000;
+// playBuffer reachable. There is no signal that separates "blocked" from "slow", so the
+// wait depends on the one fact that predicts it: whether the document has ever received a
+// user gesture (navigator.userActivation.hasBeenActive). Never activated - nothing can
+// unblock it, say so quickly. Activated - the resume() is legitimate and only waiting for
+// the audio sink to start: a few milliseconds on a device, 0.7-5 s measured on the
+// headless test fleet under load, so the wait is generous rather than a false error.
+const RESUME_GRACE_MS = 2000;
+const RESUME_GRACE_ACTIVATED_MS = 8000;
+
+function documentHasBeenActivated() {
+  const activation = typeof navigator !== 'undefined' ? navigator.userActivation : null;
+  // Unknown (older browsers): assume it has, and prefer a longer wait to a false error.
+  return activation ? activation.hasBeenActive : true;
+}
 
 // Shown by the host's status line. The remedy is the gesture: every control resumes the
 // context inside its own tap (stagePort.unlockAudio), so one tap is enough.
@@ -60,11 +72,12 @@ async function toAudioBuffer(audioCtx, input) {
 /** resume() with a deadline: see RESUME_GRACE_MS for why the deadline exists. */
 async function resumeBounded(audioCtx) {
   if (audioCtx.state === 'running') return;
+  const grace = documentHasBeenActivated() ? RESUME_GRACE_ACTIVATED_MS : RESUME_GRACE_MS;
   let timer = null;
   await Promise.race([
     audioCtx.resume().catch(() => {}),
     new Promise((resolve) => {
-      timer = setTimeout(resolve, RESUME_GRACE_MS);
+      timer = setTimeout(resolve, grace);
     }),
   ]);
   clearTimeout(timer);

avatar/stage.html

@@ -195,6 +195,11 @@
       const HANDLERS = {
         'avatar:mount': async (m) => {
           await ensureStage(m.vrmUrl);
+          // Parity with the inline transport, which constructs its context at boot: the
+          // frame's context exists from mount, so audioState reads 'suspended' - not
+          // 'none' - before the first gesture, and the strict-policy precondition holds
+          // under both transports.
+          ctx();
           return snapshot();
         },
         'avatar:speak': (m) => speak(m.payload),