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

まず ElevenLabs TTS のレンダリングパスとレスポンスヘッダーを処理するコードを見つけ、次に永続的な処理とクリーンアップが現在どのように表現されているかを追跡します。音声を返す前に history-item-id を保持し、遅延削除を再試行し、両方の履歴エンドポイントを確認し、終端エラーを通知し、読み取り用と書き込み用に分離されたスコープを使用できれば完了です。

索引モデルが issue の本文から書いたものです。