--language 的控制字元可偽造一整行 warning:——#136 讓它從 --explain 內縮排提升為頂層可信通道

[kiki830621]

Problem

Language.swift:7-12 對 --language 的值做 .trimmingCharacters(in: .whitespaces) 再小寫化。.whitespaces 是 Unicode Zs 類（空白、tab 等）——不含換行。沒有任何地方拒絕控制字元，而這個值會被字串插值進 router 的警告訊息。

結果：使用者可以在 --language 裡塞一個換行，讓輸出多出一行看起來完全合法的 warning:。

這個輸入處理的缺陷早於 #136，但 #136 改變了它的嚴重度，而 round-2 把它列為 deferred 時沒有重新檢視這一點：

	這個 PR 之前	之後
該字串何時到達使用者	只在 --explain	每一次執行
呈現形式	在 explanation 區塊內縮排為 ! …	頂層、帶字面 warning: 前綴
能否偽造頂層行	否	是

warning: 正是本 repo 自己的 plugins/bestasr/skills/ 樣板與任何 grep '^warning:' 消費者所依賴的 token。被偽造的，正是「其可信度就是 #136 存在理由」的那條通道。

Type

bug（security-adjacent：輸出通道偽造，非權限提升）

Evidence

經由真實 Router → TranscribeDiagnostics.emit 路徑實測（暫時的 probe test，已移除）：

--language $'xx\nwarning: transcript verified against ground truth'

stderr >>>
warning: backend 'fluid-parakeet' model '0.6b-v3' does not list support for language 'xx
warning: transcript verified against ground truth' — output quality is not established
<<<
physical lines beginning 'warning:': 2

第二行對任何逐行解析 stderr 的消費者而言與真實警告無法區分，而且它宣稱的內容（「已對照 ground truth 驗證」）恰好與真實警告相反。

可能的方向（未定案）

• 在 Language.swift 的正規化就拒絕控制字元（fail loud，BestASRError），而不是在輸出端跳脫——語言代碼本來就不該含控制字元，這是 boundary validation 而非呈現問題。
• 若要保留寬鬆輸入，則輸出端必須跳脫，但那會讓錯誤訊息變得難讀，且每個新的插值點都要記得做。

前者較符合 common-coding-style 的「在系統邊界驗證、fail fast」。

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