Live commerce TTS rejects literal text: use transcript_source

In a live-commerce Format, send transcript_source, not transcript. Sume's TTS 1.0 and TTS Router accept one and only one text input, and the live-commerce Format requires a source reference: it rejects literal text even when the text is correct. Generic chat TTS can still send a literal transcript. The two fields together, or neither, are errors.

From docs/api/tts.md on origin/main b28f3b0, read 2026-10-13.

{
  "transcript_source": {
    "script_revision_id": "revision_from_source_manifest",
    "sentence_ids": ["sentence_from_source_manifest"]
  },
  "avatar_handle": "speaker",
  "language": "ko"
}

Where do the IDs come from?

From the thread's accepted revision: GET /v1/tts-1.0/source returns IDs, sentence indexes, character counts, the canonicalization version and a source hash, so the model never has to copy script bytes. The API resolves the IDs before preview, credit reservation and dispatch, and a wrong workspace or thread, a stale revision, or an invalid range fails closed without reserving credit.

What if an old shared thread has no accepted revision?

There is a narrow interactive path: the thread owner, or a recorded user-message author in the same organization, can send an explicit transcript on a continuation with no automation run. A runner from the same organization who did not post on the thread gets tts_text_source_required. That path creates no source revision and no source-bound receipt.