#8103: fix(tts): sanitize API keys from error messages

## Summary Add error sanitization to TTS functions to prevent API key leakage in logs and error tracking systems (CWE-532). ## The Problem When ElevenLabs or OpenAI TTS API calls fail, error messages could potentially contain sensitive information including API keys if the underlying `fetch()` call includes request details in its error context. These errors are then logged or propagated to error tracking services, exposing credentials. ## Changes - Added `sanitizeTtsError()` function that redacts common API key patterns: - OpenAI API keys (`sk-...`) - ElevenLabs API keys (`sk_...`) - Bearer tokens in Authorization headers - `xi-api-key` header values - Wrapped error handling in `elevenLabsTTS()` and `openaiTTS()` to sanitize errors before propagation - Added comprehensive tests for the sanitization function ## Test Plan - [x] Added `src/tts/tts.sanitize-error.test.ts` with tests for all redaction patterns - [x] Verified existing TTS tests still pass - [x] Verified build succeeds ## Related - CWE-532: Insertion of Sensitive Information into Log File - OWASP A09:2021 - Security Logging and Monitoring Failures --- Internal reference: VULN-155 This PR was generated with the following prompt: > Sanitize TTS error messages to prevent API key leakage in logs (CWE-532) 🤖 Discovered by [bitsec.ai](https://bitsec.ai) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> Adds a `sanitizeTtsError()` helper to redact common credential patterns (OpenAI `sk-...`, ElevenLabs `sk_...`, Bearer tokens, and `xi-api-key` header values) and uses it when propagating errors from `elevenLabsTTS()` and `openaiTTS()`. Also introduces a dedicated Vitest suite to validate redaction behavior. This fits into the existing TTS provider implementations by ensuring provider-call failures don’t accidentally leak secrets via error messages that are logged by `textToSpeech()`/`textToSpeechTelephony()` or forwarded to error tracking. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge and improves secret-handling, with a few robustness/debuggability gaps to consider. - Changes are localized to TTS error handling and include tests, reducing regression risk. Main concerns are loss of original error context when rethrowing and incomplete sanitization if full error objects (stack/cause) are logged elsewhere. - src/tts/tts.ts (error wrapping/sanitization completeness) <!-- greptile_other_comments_section --> <!-- /greptile_comment -->