fix(vn): close translation streams after cancellation

[Lucas1479]

What and why

Cancelling VN/Host speech translation while the synchronous SDK is creating a stream can discard an unread response without closing it. Repeated cancellations consume the cached client's connection slots and can prevent both speech and subtitle translation from completing.

The bridge now owns stream creation, iteration and closure in one async iterator. It shields the current worker result, closes the stream off the audio loop, and transfers cleanup to a completion callback if cancellation happens during create/next. Cleanup waits for an active synchronous read to finish before closing the same stream. Explicit async-generator closure also covers cancellation or failure while feeding a translated piece into the TTS queue.

This is an existing lifecycle defect, independently verified against unmodified upstream 6147acbc36e2b16faa5d8192a873d40a7feb5965 on 2026-10-11. It is a follow-up to #181, not a regression introduced by #180 or #181. Client-factory consolidation remains a separate performance task.

Change class

• Routine implementation fix

Owning layer: VN bridge's synchronous translation-stream lifecycle.

User-visible effect: cancelled speech translation releases its connection so subsequent subtitle and speech requests can continue.

Compatibility or migration impact: none. Provider settings, retry policy, prompts and public contracts are unchanged. Cancellation cannot forcibly interrupt synchronous work already running; cleanup runs when that operation returns or fails.

Evidence

Environment: Windows x64, CPython 3.12.10, OpenAI 2.38.0, HTTPX 0.28.1, HTTPCore 1.0.9. All inputs and credentials are synthetic; the integration test uses only a loopback HTTP server.

• Initial lifecycle regressions against the unmodified upstream module: 8 failed. They cover normal completion, read failure, consumer closure, cancellation during create/first read/later read, and cancellation/failure during TTS dispatch.
• Real SDK regression against the same upstream module: failed with httpcore.PoolTimeout / openai.APITimeoutError after cancelling an unread stream in a one-connection pool. Fixed code completes three cancellation/subtitle-request cycles successfully using that pool.
• python -X utf8 -m pytest -q tests/test_vn_translation_stream_lifecycle.py tests/test_vn_translation_clients.py tests/test_release_tooling.py — 29 passed, including late read failure cleanup, both provider configurations, cold/warm client sharing, incremental delivery and source-release checks.
• python -m ruff check ., python tools/architecture/generate_views.py --check, python tools/architecture/generate_readme_overview.py --check, and git diff --check — passed.
• Full Python suite: python -X utf8 tools/run_tests.py --shard-count 3 --shard-index N for N = 0, 1, 2, with AMADEUS_E2E_NO_TTS=1, TTS_DEVICE=cpu and WORK_WORKTREE_ISOLATION=0 — all 441 suite files completed successfully; 5,539 passed, 23 skipped, all three processes exited 0. Remote CI is still running; this PR remains draft until those checks finish.

Final check

• One stream-ownership defect; no unrelated factory refactor
• No new public API, fallback, dependency or configuration
• No credentials, private logs, conversations or local runtime state included
• Existing third-party notices and provenance preserved