Fix CloudMail registration flow

[deguse]

Summary

• Fix cloudmail_gen by creating/registering generated CloudMail addresses before OpenAI sends OTPs.
• Update the registration start path so API/UI starts apply the latest config body before launching.
• Improve OpenAI OTP flow diagnostics and CloudMail recipient matching, plus add one-shot diagnostic scripts.
• Add registration stage metrics, standardized failure stages, async account refresh, OTP resend strategy, fast mailbox polling, and register presets.
• Document current CloudMail registration status in docs/cloudmail-registration-status.md.

Validation

• uv run python -m unittest test.test_register_proxy_runtime
• uv run python -m py_compile api/register.py services/register_service.py services/register/mail_provider.py services/register/openai_register.py scripts/test_cloudmail.py scripts/test_openai_delivery.py
• npm run build in Node 22 container for static web export.
• VPS /api/register stats verified includes avg_stage_ms, last_errors_by_stage, mailbox_provider_success, otp_wait_avg_seconds.
• VPS production staircase:
  • total=5, threads=1: success 5, fail 0, average about 10.0s/account.
  • total=10, threads=1: success 9, fail 1, failure stage openai_register.
  • total=10, threads=2: success 10, fail 0, average about 5.0s/account; one background account_refresh warning did not block registration.
  • total=20, threads=2: success 20, fail 0, average about 5.0s/account.

Operational Notes

• Runtime configs are kept under ignored data/ paths and are not included in this PR.
• CloudMail is direct by default; set mail.proxy or provider-level proxy only when the mailbox provider itself needs a proxy.
• Account status refresh now runs in the background after successful save; refresh failures are warning-only.