fix(audio): take the generation lock before loading, run on the model this request loaded

[magicnight]

The audio handlers had the same race the embedder/reranker had before #133. /v1/audio/transcriptions and /v1/audio/speech loaded (and cold-swapped) the model first, queued for the generation lock second, and then ran on whatever the slot held once the lock came free. Two consequences: a model load ran beside an LLM generation, and a request parked at the lock could have its model replaced, or the slot emptied, by the next request, so it transcribed with the wrong model or got a 500 off an empty slot. Present since v0.9.0.

What changes:

• Each handler now runs in three steps: fetch the model's files (AudioEngine.prepareSTT / prepareTTS, upstream's own resolve-or-download step, files only) outside the lock; take the lock; load and run; release. The fetch is outside the lock on purpose: audio models are pulled from the Hub on first use, a multi-GB download can take minutes, and the first version of this branch would have had every chat, embeddings and rerank request queued behind it. A repo the Hub cannot deliver (typo, gated, offline) now fails with 500 load_failed before the lock is touched. The fetch is also nonisolated, so a request's download does not wait behind a forward pass running on the engine actor.
• Concurrent fetches of one repo share a single download, process-wide (AudioSnapshotFetcher.shared): upstream clears a directory it finds incomplete, so two downloads of one repo delete each other's files, and the app's engine and the server's share one cache directory. The app's AudioServicing fetches first too, so a user who picks another file while a model is still downloading joins the download instead of restarting it.
• transcribe(model:) and synthesize(model:) check for cancellation before the load and before the inference, so the app's superseded request stops at the next checkpoint instead of loading a second copy (one superseded mid-load finishes that load and stops before the forward pass); on the server a request cancelled while the backend runs is 500 cancelled, the same code as a cancellation while waiting for the lock, and the lock is released as on any other failure. Two syntheses can still overlap on the app's engine, which has no lock of its own yet (follow-up).
• AudioEngine gets transcribe(model:...) and synthesize(model:...), which bind the model their own load produced instead of reading the slot again. The slot-reading transcribe(audioURL:) / synthesize(text:) are removed; loadSTT / loadTTS stay as preload API. The app's AudioServicing goes through the model-bound calls too: its view models cancel a superseded task and start the next one at once, and the superseded call can still be inside the engine. The app target builds.
• A swap drains MLX's buffer cache between dropping one model and loading the next, and again when the replacement's load fails, as the embedder and reranker swaps do (Reranker and embedder engines are outside the model pool budget, and a swap keeps both models loaded #130); only when a model was resident, so a failed first load never touches MLX.
• A malformed model id is answered 400 before any of this, like the lookup errors on /v1/embeddings; the validators are shared with the loaders so the server and the engine cannot disagree.
• The handlers reach the engine through a small internal AudioBackend protocol. AudioEngine is the only production conformer; the protocol exists so the tests can script the backend.
• Failure mapping covers the whole call: invalidAudioModelID → 400, modelLoadFailed → 500 load_failed, CancellationError → 500 cancelled, anything else → 500 audio_failed named after the operation. Wire codes are unchanged for every case that existed; an error of unknown type is now audio_failed rather than load_failed, which is honest since every fetch and load error is wrapped.
• The SpeechModelBox doc now says what serializes synthesis: the box's synthesize is a nonisolated async method and runs off the actor, so only the generation lock does on the server, and nothing does in the app yet (follow-up).

Tests, all under bare swift test (no weights, no Hub, no Metal):

• against a scripted backend: the fetch runs without waiting for a held lock while the load waits behind it, on both routes; a failed load releases the lock; a failed fetch is answered with the lock held and never loads; a malformed id on either route is answered with the lock held and never reaches the backend; text / verbose_json and wav / pcm replies with the model id, language, temperature and the staged upload reaching the backend; pcm at a non-24 kHz rate is a 400 and the lock is free afterwards. The backend records, from inside each call, whether the server's lock was held (generationLockIsHeld, a new internal read), so a handler that acquires and releases before loading is caught too.
• on the engine: the model-bound entry points and prepare* reject a malformed id locally and leave nothing resident; two concurrent prepares for one repo make one fetch and a different repo makes its own, with the fake fetch held at a gate until the fetcher reports the second caller has joined, so no timing is involved; a Hub failure becomes modelLoadFailed; a pre-cancelled caller stops before the load on both paths (speech against a local TTS directory with a bogus config.json, transcription with a malformed id whose validation error cannot be confused with the cancellation; neither touches the network, with or without the check). The fetch and the fetcher are injectable for these.

Mutation check, each guard broken in turn and the audio + engine suites run against it; all 18 failed as they must:

mutation (each route where it applies)	caught by
load moved ahead of the acquire	…LoadWaitsForTheGenerationLock… (answered while locked)
lock released right after the acquire, before the load	the in-call probe: lockHeldDuringCalls == [false]
release dropped on the load-failure path	lockIsFree after the 500
id validation moved behind the lock	aMalformedModelIDDoesNotWaitForTheLock
fetch moved under the lock	prepareCalls empty while locked, lockHeldDuringPrepare == [true, true], the fetch-failure test
modelLoadFailed folded into audio_failed	the load-failure tests and the mapping tests
pcm sample-rate guard removed	speechPCMAtTheWrongSampleRateIs400
fetch dedupe removed	concurrentPreparesForOneRepoShareASingleFetch
validation dropped from prepareSTT / from the load path	theModelBoundEntryPointsRejectAMalformedIDLocally and the loader tests
cancellation check before the load removed, either path	aCancelledCallerStopsBeforeTheLoad, aCancelledTranscriptionStopsBeforeTheLoad
CancellationError no longer mapped to cancelled	aCancellationIs500Cancelled

CI note: the Metal job on the first push failed two "does not wait for the lock" tests, one of them #133's embeddingsLookupAndKindErrorsDoNotWaitForTheLock, on fixed 2 s bounds; the second push failed both lock tests on a fixed 300 ms bound of my own. That job runs all 990 tests in parallel on a slow runner, where a request round trip took close to 20 s. Both test files now read the server's lock state directly instead of racing an acquire against a timer, every wait for something that must happen polls up to 60 s with the lock held throughout, and the only fixed sleeps left are followed by "has not happened yet" assertions, which a slow runner can only pass. The full suite passes locally under xcodebuild test with the same flags as the job.

Not covered by a test: that the real engine's load from the fetched files uses the bound model rather than the slot, and the second cancellation checkpoint (after the load, before the forward pass) on either path. Both need a loadable checkpoint; we still have no audio checkpoint verified on our hardware (README says so), and the binding is a few lines the review can read.

Known gap, in the CHANGELOG: the fetch covers what upstream's own first step downloads, so whatever a loader fetches on its own now happens under the lock because the load does. Six upstream speech-to-text families (voxtral, cohere, canary, wav2vec2/mms, lasr, moonshine) ignore the cache directory they are given and download a second full copy into the shared Hugging Face cache, and Whisper fetches tokenizer files from the matching openai/whisper-* repo when its snapshot lacks them; in v0.9.0 those ran outside the lock, with everything else. Kokoro's first synthesis fetches its grapheme-to-phoneme model under the lock, as it did in v0.9.0, since synthesis always ran there. Fixing the first two means passing the cache directory through in the mlx-audio-swift fork, or fetching those pieces before the lock too; follow-up.

Other follow-ups the review surfaced, none introduced here: the download is no longer stopped when a client disconnects mid-fetch (it used to run inside the load; whether Hummingbird cancels the handler on disconnect is unverified either way); model ids differing only in case get separate fetch entries but one directory on APFS; the app's engine still has nothing serializing two syntheses.