Fix Product host first-sound blockers

[knzeng-e]

Outcome

Three blockers found while deploying Dotify to Product DevNet, plus one defect
found reviewing them. Each is a first-sound problem: something between opening
the app and hearing audio.

Stacked on #114. Refs #85.

The blockers

1. Cold API machines sat directly in front of first sound

services/api/fly.toml ran min_machines_running = 0. A stopped machine
cold-starts on the first content-key request, and that request is the last hop
before playback: 8.2s to /health cold against 0.11s warm. Scaling to zero
saved nothing a listener would trade eight silent seconds for.

Now keeps one machine warm. This has a standing cost - it is a deliberate trade
of idle spend against the single worst latency spike in the listening path.

2. One slow IPFS gateway blocked every gateway behind it

The gateway reader awaited each URL in turn with no timeout, so an unresponsive
gateway cost the browser's full connection timeout before the next candidate was
even attempted - and a browser will stall a request far longer than a listener
will wait for sound.

web/src/services/gatewayRace.ts replaces that with a bounded, hedged race:

• 8s budget per attempt, time-to-headers only - once a gateway starts
  answering, the body streams at its own pace, because cutting a healthy
  download short trades a slow track for a broken one;
• a 1.2s hedge delay before racing the next gateway alongside the current one,
  so a healthy primary still serves nearly every read alone;
• at most 3 attempts in flight;
• losers aborted the moment a winner is known.

Racing is safe here because every URL addresses the same immutable CID -
whichever answers first is the same object. This is the whole-object sibling of
audioV2Gateway, which already does this for byte ranges.

3. A refused room connection said nothing actionable

Socket.IO reports connect_error identically for a CORS rejection, a stopped
server, and a wrong URL. signalDiagnostics.ts reads the signaling server's
unauthenticated /health, which already echoes its live origin allowlist
(signaling.mjs:153), and upgrades the message in place:

Situation	Message
/health unreachable	server did not answer; may be starting or offline
origin not in allowedOrigins	names the origin and says to add it to SIGNAL_ORIGINS
origin allowed, or *	generic reason - the fault is elsewhere, so do not blame configuration

This matters most inside the Product host, where the app is served from a DotNS
origin an operator has to add deliberately. It only ever widens a message; room
access stays decided by the server.

Defect found in review

The hedged race broke cancellation of the winning read.

makeAttempt detaches its parent-abort listener when the fetch settles - which
is when headers arrive, before the body streams. The winner was returned
already disconnected from the caller's signal, so aborting afterwards no longer
stopped the download.

That is a regression against the serial reader it replaced, which passed the
caller's signal straight to fetch. And it bites where it matters: useCatalog
passes a signal to every audio and asset read (useCatalog.ts:700, 856-857),
so a listener skipping tracks left the previous audio downloading to completion,
unread.

Fixed by re-linking the winner to the caller's signal before returning it, and
by aborting the winner on the late-abort path - it has already been removed from
active, so the cleanup block would not otherwise reach it. Confirmed with a
regression test that fails against the previous implementation.

Review guide

1. web/src/services/gatewayRace.ts - the race loop, the hedge/launch guard on
   caller abort, and the winner re-link.
2. web/src/features/rooms/signalDiagnostics.ts - check the message matrix
   never over-claims.
3. services/api/fly.toml - the warm-machine trade is a cost decision.

Verify carefully

• A caller abort stops in-flight reads and does not walk the remaining list.
• The winner's body is still readable after the losers are aborted.
• The hedge cannot exceed 3 parallel attempts.
• Diagnostics never claim an origin problem when the origin is allowed.
• The warm machine is worth its standing cost.

Validation

Evidence	Result
cd web && npm run test:unit	237 pass (+21 over #114: gateway race 12, signal diagnostics 8, plus the regression test)
cd web && npm run test:signal	pass
cd web && npm run lint	0 errors; the 3 pre-existing App.tsx/ArtistShell.tsx warnings remain
cd web && npm run build	pass - 4.4 MB
cd web && npm run build:product-devnet	pass - 4.4 MB
cd web && npm run smoke:production-env	pass
cd web && npm run smoke:devnet	6/6 pass against the live chain
cd services/api && npm run typecheck && npm test	pass, 92 tests
node scripts/backlog-sync.mjs --check --offline	pass; pre-existing warnings remain
git diff --check	clean

Known limitations and follow-ups

The 8s timeout and 1.2s hedge delay are fixed constants chosen from the observed
DevNet gateway behaviour, not measured optima. If DevNet gateway latency shifts,
they are the first knobs to revisit.

min_machines_running = 1 removes the cold start but not the underlying cause -
the content-key request is synchronous in front of playback. A warmed read path
or an earlier key fetch would be the structural fix.

The signaling diagnosis costs one extra /health read on a failed connection.
It runs only after a failure, and never blocks the generic error already shown.