POST/api/public/access-request/email/start-verification

向所填電郵地址發送一個 6 位數、有效 10 分鐘的確認碼——這是提交存取申請前的第一步。

`POST /api/public/access-request/email/start-verification` 啟動公開存取申請的電郵驗證。請求無須登入，並將待驗證地址置於 Body 欄位 `email`。處理成功後，系統會發送一個六位確認碼，有效期為十分鐘。 回應包含 `ok`、`verification_id`、`expires_in_minutes` 同 `resend_cooldown_seconds`。`verification_id` 必須連同同一電郵地址同收到嘅碼，喺後續嘅 Verify 路由中使用。佢唔係登入 Token，亦唔可以儲存作永久用戶識別，或者公開記錄。 呢個端點唔係冪等。多次成功呼叫可能會產生多個驗證過程或者新嘅碼。因此，基於 IP 嘅嚴格限制係每 15 分鐘最多十次請求。此外，回應會指出有 60 秒重覆鎖定。介面喺呢段時間唔應該觸發再次發送，並清晰顯示剩低嘅等待時間。 如果超出限制，路由會回應 `429 RATE_LIMIT_EXCEEDED`。如果因為送達錯誤而無法發送碼，則記錄 `502 MAIL_NOT_SENT`。呢啲情況要分開處理：速率限制透過等待解決，電郵錯誤則需要可達地址同正常送達。機密資料或者內部電郵伺服器數據唔應該出現在錯誤訊息入面。 成功情況已經用真實嘅 `verification_id` 實時驗證。相關訊息透過獨立嘅 Fake-SMTP 伺服器接收，並從真實電郵內容讀取六位碼。此外，亦觀察到多次呼叫後嘅 429 負面情況。只可以提及呢個證明；由此仲推唔出存取申請已成功完成或者支付過程已完成。

{"email":"max@example.com"}

{"ok":true,"verification_id":"<UUID>","expires_in_minutes":10,"resend_cooldown_seconds":60}