regression gate 對 FluidAudio 後端零覆蓋——baseline 12 列全是 large-v3-turbo

[kiki830621]

Problem

scripts/regression-gate.sh 是 release 的阻擋閘，但它的 baseline 完全不含任何 FluidAudio 後端：

benchmarks/baseline.json   12 rows
models 集合                 ['large-v3-turbo']      ← 單一值
grep -c fluid  baseline.json            → 0
grep -c fluid  scripts/regression-gate.sh → 0

也就是說 fluid-parakeet / fluid-paraformer / fluid-sensevoice 三個後端的準確度，沒有任何自動化保護。一次讓它們退化的改動——依賴升級、模型換 row、解碼參數調整——不會被任何 gate 攔下。

Type

bug（測試覆蓋缺口）

為什麼現在開：這是第三次被丟掉

何時	發生什麼
PR #142 round 1	regression lens 提出，判 HIGH。但它沒有進到 round-1 的 findings 表——synthesis 步驟弄丟了
PR #142 round 2	重新被提出（R2-H），結論是「belongs in a follow-up issue rather than in a dependency bump」。issue 沒有被開
PR #142 round 3	三個 verifier 各自獨立確認缺口仍在，且五個 deferred 項目一個都沒開單

一件事被「應該另開 issue」處理三次而三次都沒開，實際效果等同於它在每次 merge 的那一刻消失。所以這次先開單，再談要不要做。

為什麼它特別要緊

FluidAudio 是這個 repo 依賴變動最頻繁的上游（#110 → #122 → #123 / #124 一整條線），而它正好是唯一沒有 gate 覆蓋的後端家族。PR #142 的三輪驗證裡，「這次升級有沒有動到準確度」全靠人工 A/B 回答——因為沒有任何自動化的東西能回答它。

需要先決定的（所以這不是「加一列就好」）

• 語料：baseline 用的是 canonical 社群語料，而 FluidAudio 後端在中文語料上的表現（fluid-paraformer 的 CER ~179–182%）目前被 release-sweep.sh:16 明確標為 known-broken 並預設排除。把一個已知壞掉的後端放進 gate，要先決定 baseline 值該記什麼。
• 哪些 row：三個後端 × 語言 × 模型，全放會讓 gate 變慢很多；只放 fluid-parakeet 的英文 row 可能是合理起點。
• 與 benchmark 無法在不污染 durable measurement store 的情況下執行（無 --store-dir，HOME 覆寫無效） #160 的關係：跑 baseline 量測會寫 durable store，而目前沒有 --store-dir。

相關

#122 / PR #142（round 1 → 3）、#160（store 無法導向）。