fix: review findings — clone-route audio sniffing, zip caps, filename sanitization, WAV response caps

- speakWithReference now validates the response IS audio via the same
  audioResultMIME sniff the sfx/enhance surfaces use — a 2xx JSON soft
  error or HTML proxy page was previously wrapped up as audio/wav bytes.
- audioResultMIME moves to audio.go (next to speechMIME; it was defined
  in sfx.go but shared by enhance/clone) and learns the Ogg container
  normalization (application/ogg -> audio/ogg).
- Stems zip unpack gains entry-count (16) and total-decompressed (1GB)
  caps on top of the existing per-entry cap — the per-entry bound alone
  still let a many-entry bomb multiply up.
- sanitizeFilename drops NUL and both path separators too, so upload
  metadata can never smuggle directory structure to a file-writing shim.
- New maxAudioResponseBytes (256MB) for bodies that ARE one audio clip
  (clone, enhance, sfx): a long WAV legitimately passes the 64MB JSON
  cap.
- speakWithReference local renamed path -> upPath (naming parity with
  stems/enhance).

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WWCQcYStWXBYUy5sZWnbLT

provider/llamaswap/llamaswap.go

@@ -53,6 +53,12 @@ const maxResponseBytes = 64 << 20
 // can't allocate without limit.
 const maxVideoResponseBytes = 512 << 20
 
+// maxAudioResponseBytes caps bodies that ARE a single encoded audio clip
+// (voice clone, speech enhancement, sfx): a long uncompressed WAV
+// legitimately passes the 64MB JSON cap. Still bounded so a buggy upstream
+// can't allocate without limit.
+const maxAudioResponseBytes = 256 << 20
+
 // Provider is a llama-swap client. It satisfies llm.Provider (chat, delegated
 // to provider/openai) and imagegen.Provider (image generation), and exposes
 // llama-swap's management endpoints as concrete methods.