feat: tts develop skills

[YiminW]

No description provided.

[github-actions]

1. [P2] Include the initializer that registers the generated addon — SKILL.md:14

   The required package layout omits __init__.py. TEN's Python addon loader imports ten_packages.extension.<name>, rather than its addon submodule (packages/core_addon_loaders/python_addon_loader/src/main.cc:270–279). With this layout, importing the namespace package never executes the registration decorator in addon.py, so the generated extension cannot load. Please require __init__.py containing from . import addon in the layout and package self-check, as the existing TTS extensions do.

2. [P2] Separate connection reporting from the inherited request state machine — references/common.md:42

   The existing connection callbacks support only connecting, connected, and disconnected; the connection-status guarder explicitly rejects other values (tests/test_connection_status.py:183–190). Request states are separately managed by AsyncTTS2BaseExtension, which enters PROCESSING and FINALIZING before calling request_tts. Requiring nine states through existing callbacks, with different transition timing, cannot be implemented using that contract. Please specify on_connecting/on_connected/on_disconnected for transport reporting and identify any additional provider states as internal observations, with send timestamps recorded separately for TTFB.

3. [P2] Require base-class finalization after streaming terminal output — references/common.md:70

   The completion action and self-check never require await finish_request(...) for adapters inheriting AsyncTTS2BaseExtension. send_tts_audio_end() emits the event but leaves _processing_request_id active; finish_request() releases buffered requests and completes the state transition. An adapter following only the documented output sequence can finish request A visibly while buffering request B indefinitely. Please document this required call for normal, empty, and error completion, preserve the base class's ownership of flush cleanup, and require a test that a second request ID proceeds after the first completes.

4. [P2] Distinguish vendor chunk completion from TEN request completion — references/common.md:70

   The mapping unconditionally closes the TEN request on provider completion, although several text inputs can share one request_id. For a serialized provider that emits an END per text chunk, the END for (A, "hello", text_input_end=False) must leave A open for subsequent chunks. Closing it here either drops appended text or produces multiple start/end pairs for A. Existing deepgram_tts explicitly distinguishes intermediate END from final END, and test_append_input checks one lifecycle per group. Please qualify the mapping with logical input completion and drained provider work, and add that appended-input scenario to the acceptance checks.