轉錄失敗時 router warnings 全部消失——#136 的開場範例原封不動搬到失敗路徑上

[kiki830621]

Problem

CommandCore.swift 在呼叫引擎之前就算出 rec（含 warnings），但 warnings 只掛在 TranscribeOutcome 上，而 TranscribeOutcome 只在成功時存在：

:350-351   let rec = try router.recommend(...)      // warnings 在這裡就有了
:357       let result = try await engine.transcribe(...)   // 這裡拋出 → 下面全部不執行

引擎拋出時 runMapped 只印 error: …，TranscribeDiagnostics.report 從未被呼叫。所有 router warnings 靜默消失。

具體情境就是 #136 自己的開場範例：使用者 --backend fluid-parakeet，該 backend 不可用 → 產生替換警告 → 替換後的引擎失敗。使用者被告知「執行失敗」，但不會被告知跑的根本不是他要的 backend。

而在失敗路徑上知道發生過替換，比在成功路徑上更有用——那是「為什麼失敗」的第一個候選解釋。

Type

bug

Evidence

• CommandCore.swift:350-351（rec 計算）vs :357（engine.transcribe），中間沒有任何 warning 輸出。
• BestASRCommand.swift 的 runMapped catch 區塊只寫 error: 一行。
• 全 repo grep：rec.warnings 的唯一去處是 TranscribeOutcome(...) 的建構，而該建構在 transcribe 成功之後。

先前存在，非 #141 引入。但 #141 的新架構把它固化了：在此之前 warnings 只是 explanation 字串的一部分（同樣掉失，但沒有結構）；現在 warnings 是 TranscribeOutcome 的一個欄位，而該型別的生命週期定義上就是「成功」。要在失敗時把它們攤出來，不再是搬一行的事。

可能的方向（未定案）

• 讓 warnings 的載體與成敗解耦（例如在 recommend 之後、transcribe 之前就 emit，或讓 error 型別攜帶 diagnostics）。
• 注意順序：若改成 recommend 後立刻 emit，成功路徑上 warnings 會出現在轉錄期間而非結束時，這對長檔案反而更好，但會動到 fix: router warnings never reached the user without --explain (#136) #141 剛釘住的 ordering 契約——需要一併重新評估那組測試。

發現於 PR #141 round-3 verify（logic lens，L5）。相關：#136。