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."

Start by locating the ElevenLabs TTS render path and the code that handles the response header, then trace how durable work and cleanup are currently represented. Done means retaining the history-item-id before returning audio, retrying delayed deletion, checking both history endpoints, alerting on terminal failure, and using separate read and write scopes.

Scritto dal modello di indicizzazione a partire dal testo della issue.