feat(admin): 司機評價欄與訂單評分呈現（B5 下游）

[thothawei]

評分（B5）上線後只有司機自己看得到。營運方要能一眼找出評價低的司機，
客服要能回答**「這位乘客給了幾分、寫了什麼」**。

依賴後端 PR：fleet-dispatch#47
（/admin/drivers 的 rating_avg／rating_count、/admin/rides/:id 的 rating）。
後端未合併時 normalizeDriver 自然歸零、顯示「尚無評分」，不會壞掉。

改了什麼

• Driver 型別加 RatingAvg／RatingCount；normalizeDriver 走既有的 num()，
  舊後端不帶 rating_* 時自然歸零＝「尚無評分」，不需另做缺鍵判斷。
• 司機管理頁「評價」欄：有評分顯示星＋平均＋則數（tooltip 說明幾位乘客評的）；
  沒評分顯示「尚無評分」而非 0.0——0 則不代表差，渲染成 0.0 顆星會看起來像被評成 0 分。
  可排序，且沒評分的一律排最後（不該混進低分名單）。
• RATING_COLOR：< 3.5 紅、< 4.5 黃、其餘金。低分要一眼看得出來，那是營運會採取行動的訊號；
  門檻純呈現用，不參與任何計算或派單邏輯。
• 訂單詳情加「乘客評分」卡：唯讀 Rate ＋ 分數 ＋ 時間 ＋ 評論；
  只給星等沒留言時明說，未評分整塊不顯示（沒評不是缺資料，空卡片只會讓人以為壞了）。

驗收

• tsc --noEmit 無誤、oxlint 乾淨、vitest 123 passed（原 118＋新 5）。
• 反向確認：拿掉排序的「沒評分排最後」特例，該案會 FAIL（實測）。
• 瀏覽器實跑（dev server ＋ dispatch docker compose）：
  • 司機列表顯示 4.5 (2) 與「尚無評分」，與 API 回的 rating_avg=4.5 rating_count=2 一致。
  • 訂單詳情顯示「5 / 5」＋評論「服務很好」，Rate 為 disabled（admin 不能改乘客的評分）。
  • 未評分的訂單 feat(admin): 統一錯誤處理層、司機搜尋/詳情頁、地圖連動、Skeleton、登出確認 #3 沒有「乘客評分」卡片（DOM 斷言 hasRatingCard: false）。

既有 normalizeDriver 的 toEqual 測試因形狀多兩個鍵而 FAIL，已更新並補上
「舊後端缺鍵時歸零」的斷言——形狀確實變了，不是把斷言改弱。

🤖 Generated with Claude Code