feat: 新增注册业务维度以及获取同provider下不同邮箱

[africa1207]

• 根据业务project维度定义used状态
• 可获取不同provider下不同email_domain

Pull request type / PR 类型

Please check the type of change your PR introduces / 请勾选 PR 引入的更改类型:

• Bugfix / Bug 修复
• [ x ] Feature / 新功能
• Code style update (formatting, renaming) / 代码风格更新（格式化、重命名）
• Refactoring (no functional changes, no api changes) / 重构（无功能更改、无 API 更改）
• Build related changes / 构建相关更改
• Documentation content changes / 文档内容更改
• Other (please describe) / 其他（请描述）:

What is the current behavior? / 当前行为是什么？

Issue Number / Issue 编号: N/A

What is the new behavior? / 新行为是什么？

Other information / 其他信息

[ZeroPointSix]

已经合并到dev分支上面，等到下个版本测试完成，会正式合并到main分支

[ZeroPointSix]

已接入

[ZeroPointSix]

总体结论：本轮巡检覆盖 PR #27 当前 head c597effb18fae11701a08f81619643c54dbdd830。项目级邮箱池复用和按 email_domain 领取的方向是合理的，但 claim 级读信路径缺少当前 API key/consumer 与 claim 所属 consumer 的一致性校验，建议合并前修复。

关键发现：

• 阻塞：outlook_web/services/external_api.py 的 resolve_claim_context() 通过 pool_service.get_claim_context(claim_token=...) 解析 claim 后，只调用 ensure_external_email_access(claim_email)，没有校验 claim_context["consumer_key"] 是否等于当前请求的 get_external_api_consumer()["consumer_key"]。影响是：只要另一个外部调用方拿到或猜到有效 claim_token，就可能用自己的 API key 调用 verification-code / verification-link / wait-message 读取该 claim 对应邮箱的上下文。release_claim() / complete_claim() 已经校验 consumer，但读信链路没有同等隔离。
• 高：建议把当前 consumer 传入 resolve_external_mail_scope() / resolve_claim_context()，或者在 resolve_claim_context() 内部读取当前 consumer，并在 claim_context["consumer_key"] 非空且不匹配时返回 403，例如 CLAIM_CONSUMER_MISMATCH。这应当在所有 claim_token 读信入口生效，而不是只在 pool complete/release 生效。
• 中：建议补一条回归测试：API key A claim 出邮箱后，API key B 使用同一个 claim_token 调用 /api/external/verification-code 应返回 403，且不能触发 Graph/IMAP 读信；同一 consumer 下的正常 claim_token 读信仍应通过。
• 低：文档已经建议 claim 级读信优先使用 claim_token，因此这里的隔离语义最好也写进文档：claim_token 只能被原 consumer 使用，不能跨 API key/consumer 复用。

优先级建议：

• 阻塞：补上 claim_token 读信的 consumer 隔离校验。
• 高：补跨 consumer 负例测试，防止后续外部 API 重构时回退。
• 中：确认 get-messages / latest-message / verification-code / verification-link / wait-message 这些 claim_token 入口全部走同一校验函数。

后续建议：

• 修复后建议重跑外部 API 与邮箱池相关测试，尤其是 tests/test_external_api.py 和 tests/test_pool_flow_suite.py。如果要保留 legacy claim（claimed_by 中没有 consumer_key）的兼容窗口，也建议明确只允许 legacy claim 在原有单 consumer 场景下读取，避免多 consumer 部署中出现模糊授权。