fix(admin): patchDriverStatus 正規化回傳值（型別原本在說謊）

[thothawei]

怎麼找到的

admin REST 形狀對帳：起真後端，逐端點抓實際回應比對前端的型別與 normalizer。

結論是 admin 的契約基本乾淨（詳見下方），只揪出這一個型別謊言。

問題

PATCH /admin/drivers/:id/status 實際回：

{"driver":{"ID":1,"LineUserID":"...","Name":"...","Phone":"","Status":3,
           "vehicle_type":"sedan","plate_number":"LI-3748",
           "vehicle_review_status":"approved","vehicle_review_note":"",
           "CreatedAt":"...","UpdatedAt":"..."}}

混合大小寫（ID／Name／Status 走 Go 欄位名，車輛欄位走 json tag），而且不含 rating_avg／rating_count。

前端卻宣告它回 Driver（全 PascalCase）且不正規化——VehicleType／PlateNumber／VehicleReviewStatus／RatingAvg／RatingCount 全是 undefined。

目前 runtime 沒出事：兩個 mutation 都丟掉回傳值只做 invalidateQueries，重抓那條有 normalizeDriver。但型別在說謊——哪天有人拿它去 setQueryData 做樂觀更新，那一列的車種車牌就會憑空消失，而且不會有任何錯誤。這正是今天修的那幾個 bug 的前身形狀。

修法

改吃 Record<string, unknown> 並走 normalizeDriver，讓宣告的型別成真（reviewDriverVehicle 本來就是這樣做的，兩支現在一致）。

測試

mock 換成從真後端抓下來的混合大小寫形狀——舊 mock 只有 PascalCase，所以這個問題測不出來。斷言車輛三欄正確、RatingAvg／RatingCount 補 0 而非 undefined（表格排序吃 undefined 會壞）。

反向驗證：改回不正規化 → 該案 FAIL。

驗收：npm test 134 passed、npm run lint 乾淨、tsc --noEmit 通過。

這輪 admin REST 對帳驗過乾淨的部分

檢查	結果
/admin/rides 列表 8 個鍵 vs RideRow	完全一致，OrdersPage 只渲染這些
六個篩選參數（status／limit／offset／from／to／q）	名稱一致，且實跑證明真的有篩（負向對照：status=9→0、不存在關鍵字→0、未來日期→0）
分頁 total	limit=1 時仍回全量 2，antd 分頁不會壞
/admin/rides/:id 頂層 events／ride／track_geojson／stops／rating	與 fetchRideDetail 的解析一致；rating 造一筆評分過的訂單驗到 score／comment／created_at
日報表／月報表欄位	與 DailyReportRow／MonthlyReportRow 完全一致
/admin/lost-items 13 個鍵	與 LostItem 完全一致（含 customer_name／driver_name）
會費帳單（產生→列表→標記已付）	7 個鍵與 MembershipInvoice 一致；period 鍵名正確
/admin/drivers 列表	混合大小寫 ＋ rating_avg／rating_count，normalizeDriver 兩種都吃

🤖 Generated with Claude Code