長時間工作改成 202 加 workflowId 輪詢

同步 API 撐不住長時間工作（連線 timeout、proxy body-size、使用者不知道進度）。標準改法是：立刻回 202 + 一個 workflowId，把結果丟到物件儲存，客戶端輪詢狀態、完成後再下載產物。

POST /validate  → 202 { workflowId }
GET  /status?workflowId=…  → { status, progress, counts… }（輪詢）
POST /download  → 二進位產物

幾個實作要點

產物不要走工作流引擎的 payload：Temporal 這類引擎的 payload 有上限（預設約 2MB），activity 的輸入輸出只放 fileId / 物件儲存路徑 / 各種 count 等小字串，大檔案一律走 GCS/S3
進度要分清真假：真進度是按已處理量內插的，假進度是固定檢查點或只為了餵飽 heartbeat timeout 的定時器。心跳存活 ≠ 有進展——用 setInterval 重送同一個百分比會讓卡住的工作看起來仍在跑
沒有結果時就不要編：狀態回應可以省略 progress 欄位，不要猜一個數字
重試語意要想清楚：如果每個步驟都是大型非冪等操作，通常會設成不自動重試，由客戶端重新發起——那就要確保客戶端手上還留著重送需要的東西
改造既有 endpoint 時保留舊路徑：用 Content-Type 分流（JSON 走舊的同步路徑、octet-stream 走新的），否則舊客戶端會直接壞掉 → 契約 breaking 又沒有分流時，前後端不能分開部署