notes from ElevenLabs TTS experiment

Alert text is user data. Design for minimizing what ElevenLabs ever holds; deletion is cleanup, not prevention.

**`enable_logging=false` does not work.** Measured: a ZRM request returned HTTP
200 *and* a `history-item-id` header — it wrote a history entry exactly like the
logging-on request, with no eligibility error. ZRM is gated to eligible
Enterprise accounts; on a normal key the parameter is accepted and silently does
not apply. Never treat a 200 as proof of non-retention.

**Deleting the history item does work, but not immediately.** Measured at +3 ms
after the audio response completed:
- `DELETE /v1/history/{id}` → **404 `history_item_not_found`**
- `GET /v1/history/{id}/audio` → **200, audio present**

The audio is live and fetchable on their servers *before* the history record is
addressable for deletion. A 404 on DELETE means "not there yet", not "nothing
stored" — never infer deletion from it.

**Therefore: a delayed delete queue, not an inline delete.**
- Persist the `history-item-id` (response header) durably **at render time**,
before returning audio to the user. It is the only handle; a crash between
render and delete orphans data nothing can later remove.
- Delete after a delay, with backoff retries on the not-found case.
- **Alert on terminal failures.** A failed delete is silent and leaves live audio.
- The delay is unmeasured — a 0/250/750/2000/5000 ms ladder was written but never
confirmed against the live API. Measure it and set the first attempt past the
window; don't assume.

**Verification must handle inconsistent error shapes.** DELETE-missing is `404`,
but `GET /v1/history/{id}` on a missing item is **`400` with
`detail.status: invalid_id`** (not 404). Check *both* the history item and its
`/audio` endpoint — in one run the audio outlived the record.

**Keys need their own scopes for cleanup:** `speech_history_write` to delete,
`speech_history_read` to verify. A TTS-only key gets `401 missing_permissions`
and the cleanup silently no-ops. Provision this before launch.

**Even a verified delete is weaker than ZRM.** ElevenLabs states debugging and
moderation logs may retain related data, and backups may persist up to 30 days.
User-facing copy must say "deleted from history" — never "never stored."

Commencez par localiser le chemin de rendu ElevenLabs TTS et le code qui gère l’en-tête de réponse, puis suivez la manière dont le travail durable et le nettoyage sont actuellement représentés. Le travail est considéré comme terminé lorsque la history-item-id est conservée avant le retour de l’audio, que la suppression différée est réessayée, que les deux endpoints d’historique sont vérifiés, qu’une alerte est émise en cas d’échec terminal et que des scopes de lecture et d’écriture distincts sont utilisés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.