feat(#45): 通知 slot 底座 + 遷移危險修復 + 退回必發回條 (P0-5)

[poterpan]

UX 健檢批次 C（#45）的第一批：通知 slot 底座、遷移危險修復，以及 P0-5 的主軸「退回必發回條」。

本 PR 刻意不涵蓋 #45 的全部 16 項任務——這批本身完整且獨立，而且含有一個會破壞正式環境資料的修復，值得先落地讓 main 穩定（#44 / #46 的 rebase 基準也才穩）。

🚨 最重要的一項：修掉會靜默清空正式資料的遷移

本分支原有 0006_notification_event.sql，與已上線的 #48 0006_overdue_daily.sql 撞號。更嚴重的是它的搬移語句把 event 硬寫成空字串：

SELECT ..., subscription_id, '', ...   -- ❌ 會清空 #48 的逐日 day-key

分支切出去時這是對的（那時 event 欄還不存在），但 #48 已上線，正式環境的 notification_logs.event 現在存著逐日催繳的 day-key。照原樣套用會：

• 把所有 day-key 清成 '' → [Feature] 催繳邏輯改善 #48 的「每日催繳」退化成「每期一則」
• 完全無聲：不報錯，測試也抓不到（測試環境從 0001 重跑，重建的 SELECT 永遠碰不到測試列）

修法：改名 0007_notification_event.sql、event 改為原值傳遞、不重新宣告已存在的欄位，本次重建只把 type CHECK 擴充加入 'nudge'。

驗證方式（不是靠測試，因為測試根本測不到）：用 sqlite3 實際重放 0001 → 0007，種一筆帶 day-key 的 overdue 列：

版本	結果
修正版 0007	event = 2026-08-29 ✅ 保留
反證（換回 ''）	event = '' ❌ 確實被清空

這個限制已寫成註解留在 test/schema.test.ts，避免後人誤以為有測試保護。

rebase：兩套語意都保留

分支基底是 #48 之前的 main，core/notify.ts 與 core/billing.ts 有實質衝突（非單純文字衝突）。已手工合併，兩邊都保留：

• [Feature] 催繳邏輯改善 #48：claimNotificationSlot / releaseSlot / dayKey 逐日去重
• [UX-C] 成員回饋迴路 #45：releaseNotification / releaseReceiptSlots / receipt / nudge

P0-5：退回必發回條

成員送出繳費被退回後，過去完全收不到任何通知——這是 UX 健檢列為 P0 的死路。

• 新增 core/receipt.ts 的 announcePaymentReceipt：以 (帳單, event) 為去重鍵，退回與確認是兩個 slot
• 一位成員同期多筆合併成一則訊息，不是 N 則（一鍵全部核准會驗 N 筆）
• 沒有頻道或 bot token 時不佔用 slot（同 cron 規則），之後設定好才不會撲空
• 送失敗把 slot 還回去，避免這張帳單的回條被永久靜音
• 成員重新送出時釋放該期回條 slot——下次審核是新事實，要能再講一次
• 接上 POST /admin/payments/:id/reject：退回已提交，Discord 失敗不轉成 500，誠實回報 notified 筆數

測試

382 passed / 53 files（main 基準 355）。pnpm -r typecheck 綠，admin + web build 皆綠。

新增涵蓋：回條去重、跨 event 分離、多筆合併成一則、重送後可再發、送失敗還 slot、無投遞管道不佔 slot、路由層退回會記錄、Discord 失敗不 500。

尚未涵蓋（#45 後續 PR）

Task 4–16：確認回條開關、P0-6 錯誤中文化、C1–C9（金額收斂、三入口能力差異、/我的帳單、綁錯名字、個別催繳、未綁定成員可見度等）。

審查註記

Codex 跨引擎審查因額度用盡尚未執行，額度恢復後補送（owner 已知悉）。