fix(web): a rider is hard to understand for the first ~30 s after joining voice

[janlauber]

Reported on a real ride: when a rider newly joins voice, the room can barely
understand them, and it gets better after a while.

The reflex is "Chrome's noise suppression", but that is off — MIC_CONSTRAINTS
(web/src/lib/room/capture.ts:29) ships noiseSuppression: false exactly as
ADR-0043 decided. A suppressor
is also bad consistently; "bad at first, better later" is something
converging. Three things converge on a fresh join:

1. autoGainControl: true (capture.ts:32) — Chrome's adaptive digital
   gain starts conservative and climbs over ~10–30 s. The rider is too quiet
   and gets louder. Note this is load-bearing, not a free toggle: fix(web): AGC off made everyone quiet and killed ducking — a #524 regression #555 found
   that turning AGC off killed ducking and made everyone quiet, and every
   stored gate threshold is calibrated against it.
2. NetEq's jitter buffer, subscriber-side — a cold stream over-buffers and
   conceals aggressively until it learns the path. This is the one that sounds
   garbled rather than quiet.
3. echoCancellation: true (capture.ts:31) — the adaptive filter
   over-attenuates until it converges, much worse on speakers than headphones.

A fourth, weaker candidate: a rider with no tuned gate threshold gets chopped
(gate.ts, GateTune.svelte) — but that does not improve on its own, so it
only fits if they are also adjusting it or speaking up.

How to tell them apart — no code required

By ear first: too quiet, then louder is the AGC; muffled or warbly, then
clear is the jitter buffer.

Then confirm on the next real ride with chrome://webrtc-internals open while
someone joins, watching the first 30 seconds of:

• audioLevel (rises → AGC)
• concealmentEvents / concealedSamples (high then falling → jitter buffer)
• jitterBufferDelay

Whichever curve moves names the cause. Do not reach for a noise suppressor
before that is known — RNNoise and friends are the wrong shape of fix for a
convergence problem, and ADR-0043 parked them for separate reasons that this
report does not touch.

Related: #152 (audio quality bar — the listening pass, ears required) is where
this belongs if it turns out to be a tuning question rather than a defect.