Add sandbox-only aai speak streaming TTS command

[alexkroman]

What

Adds aai speak — synthesize speech from text via the sandbox streaming-TTS WebSocket, playing it through the speakers by default or writing a WAV with --out.

aai speak "Hello there, friend." --sandbox       # play through speakers
aai speak "Hello" --out /tmp/hello.wav --sandbox # write a WAV
echo "Hello" | aai speak --sandbox               # text from stdin
aai speak "Hi" --voice jane --language English --sandbox --json

Sandbox-only: TTS only exists at streaming-tts.sandbox000.assemblyai-labs.com. Running against production (the default) exits 2 with a --sandbox hint.

How

• aai_cli/tts/ — new subsystem mirroring agent/:
  • session.py — the WebSocket protocol (Begin → Generate → Flush → Audio → Terminate) with an injectable connect factory for hermetic tests; auth/connect failures map to clean CLIErrors. Boundaries are typed via Protocol, not Any.
  • audio.py — write_wav (stdlib wave) and play_pcm (sounddevice).
• commands/speak.py — the Typer sub-app (sandbox guard → key → text from arg/stdin → synthesize → play or write; --json metadata).
• environments.py — new streaming_tts_host field; empty on production (the sandbox-only signal), set on sandbox000.
• main.py — registers speak under "Run AssemblyAI".

Design + implementation plan: docs/superpowers/specs/2026-06-10-aai-speak-design.md, docs/superpowers/plans/2026-06-10-aai-speak.md.

Tests / gate

Full ./scripts/check.sh is green: ruff, mypy, pyright (src strict + tests), vulture, deptry, import-linter, xenon, 100% patch coverage, mutation gate (no surviving mutants), no-new-escape-hatches (zero net-new Any/cast/ignores), build + twine. New unit tests cover the protocol (incl. error/warning frames, auth mapping, default factories), WAV/playback, and the command surface; help snapshots regenerated.

⚠️ Known limitation — upstream not synthesizing (server-side)

The deployed sandbox upstream currently rejects all synthesis. Verified directly against the live server (raw client, no CLI involved):

• The connection succeeds — Begin echoes configuration: {voice, language, sample_rate}.
• On Flush the server returns {"type":"Error","error_code":3005,"error":"Upstream error: InputParseError"} and closes with code 3005.
• It fails identically for every voice/language/text — even with no Generate at all (just Flush), and for the exact documented sample_session.py request. So the upstream model throws InputParseError on the gRPC Initialization, before any text. This is a server-side gateway↔model contract mismatch, not a CLI bug — no client change can affect it.

The CLI faithfully reproduces the reference protocol; it should work once the sandbox upstream is fixed. End-to-end audio could not be verified while the upstream is down.

Open follow-up

• Revisit the client-side --voice/--language defaults (currently Vivian/English). These were added on a since-disproven hypothesis that the bare command failed for lack of voice/language; the server actually defaults them. May revert to "no client default" (server is source of truth).

🤖 Generated with Claude Code