feat:實作通知系統 — 站內通知、Email 通知、Polling 機制

後端
- 新增 6 個 Notification class（預約建立/確認/拒絕/取消/完成、收到評價），database + mail 雙 channel
- 新增 NotificationController（list / unread-count / markRead / markAllRead / destroy）
- 整合通知觸發至 MemberBookingController、ProviderBookingController、CompleteFinishedBookings、ReviewController
- 新增 notifications / jobs / failed_jobs migration
- Docker Compose 加入 queue-worker、mailpit service
- DivingOffer 補上 provider() 關聯

前端
- 新增 notificationStore（Polling 30s/60s 自適應 + Page Visibility API）
- 新增 NotificationBell（未讀 Badge）、NotificationDrawer（側邊通知中心）
- main.js：auth store init 前置於 router.use()，修正 beforeEach guard 時序問題
- notificationAxios：依路徑動態選擇 member/coach token
- NotificationDrawer：改用 new URL().pathname 提取 action_url 路徑

OpenSpec
- 歸檔 notification-system change
- 同步 notification-core / notification-email / notification-triggers specs 至主規格
- 更新 booking-lifecycle / review-lifecycle spec（補充通知觸發 requirement）

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

openspec/changes/archive/2026-05-17-notification-system/specs/booking-lifecycle/spec.md

@@ -0,0 +1,15 @@
+## MODIFIED Requirements
+
+### Requirement: 預約狀態轉換觸發通知
+
+預約七狀態機（`pending` / `confirmed` / `completed` / `rejected` / `expired` / `member_cancelled` / `provider_cancelled`）的每個轉換點，系統 SHALL 在狀態成功更新後觸發對應通知（詳見 `notification-triggers` spec）。通知觸發 MUST 在主業務 transaction commit 之後執行，且以 try/catch 包裹，不影響主業務結果。
+
+#### Scenario: 狀態轉換後通知觸發
+
+- **WHEN** `BookingService` 中任一狀態轉換方法成功執行
+- **THEN** 對應的 Notification class 被觸發，不論通知是否成功主業務均正常回傳
+
+#### Scenario: 通知失敗不影響主業務
+
+- **WHEN** notify 呼叫拋出例外
+- **THEN** 預約狀態已正確儲存，HTTP response 成功回傳，錯誤記錄至 Laravel log