feat: add Cloudflare email generator with routing lifecycle controls

[Liu8Can]

但我用二级域名百分百会触发 手机号验证

1. 新增 邮箱生成 选项，支持 DuckDuckGo 与 Cloudflare Routing。
2. 新增 Cloudflare 配置项：CF 域名、CF Zone ID、转发到、CF Token。
3. 接入 Cloudflare Email Routing API，自动创建随机前缀邮箱并写入流程。
4. 新增路由生命周期管理：创建新前缀前清理旧路由、Step 9 完成后自动清理、重置与新一轮前兜底清理。
5. 新增传播等待窗口（当前 3~5 秒）并在 Step 3 前自动等待。
6. 修复 Duck 地址生成稳定性：增强多语言按钮识别，避免重复复用旧邮箱。
7. README 补充 Cloudflare 参数获取与配置教程。

[black-zero358]

按照目前这个扩展的流程，只是搞codex验证的话，不需要过手机号验证吧

[QLHazyCoder]

codex-5,4审查回复：
我看了下 #12，整体方向是对的，改动也比较完整：

1. 把邮箱生成从只支持 Duck，扩展成了 Duck / Cloudflare 两种模式
2. 侧边栏增加了 Cloudflare 的配置项
3. background 里接入了 Cloudflare Email Routing 的创建、删除和 Step 3 前的传播等待
4. Duck 邮箱生成按钮识别也做了增强
5. README 也补了 Cloudflare 的配置说明

这些思路本身都合理，Cloudflare API 的接入方向也没明显问题。

不过这个 PR 目前我觉得还不适合直接合并，主要有几个问题：

1. Cloudflare 旧路由删除失败时，后续流程还是会继续
   比如重新获取邮箱、自动运行新开一轮、或者 reset 的时候，cleanupCloudflareRoutingRule() 失败了只是记日志/返回 false，但外层不会中断，还是继续创建新路由或者继续 reset。
   这样会导致：

• 旧规则删不掉，但新规则继续创建
• cloudflareLastRuleId 被新规则覆盖
• 原来那条旧规则后面就彻底失去追踪，没法自动清理了

这个是当前最核心的问题，因为 PR 里主打的就是“路由生命周期管理”，但现在失败场景没收住。

2. 删除路由时依赖的是“当前配置”，不是“创建时配置”
   现在创建成功后只保存了 ruleId / alias / readyAt，但删除时会重新读取当前的 Zone ID / Token。
   如果用户在生成邮箱后改了 Cloudflare 配置，再到 Step 9 或 reset 时去删规则，就可能拿错 zone 或 token，导致旧规则删不掉。

也就是说，删除逻辑依赖可变配置，这里不稳。

3. Cloudflare Token 的存放方式有安全隐患
   现在 cloudflareApiToken 会进入持久化配置，而且又被同步进 session state。
   项目里 session 还开放给了 untrusted contexts，GET_STATE 也会直接返回整个 state。
   这样相当于 content script 侧也有机会读到一个带 Email Routing 写权限的 token，这里是明显的安全回归。

其他部分我看下来：

• Duck 按钮识别增强这块是合理的
• README 补充也没问题
• Cloudflare Step 3 前增加几秒等待，这个思路也合理

所以我的建议是：

1. 先把 Cloudflare 路由删除失败时的处理补严，至少不要在失败后继续覆盖旧 ruleId 或直接 reset 掉状态
2. 创建成功后把删除所需的关键元数据一起保存，删除时不要依赖用户当前改过的配置
3. Token 不要直接暴露到可被 content script / GET_STATE 拿到的整份状态里

等这几个问题补掉之后，这个 PR 再合并会更稳一些。

[github-actions]

AI 审查需要人工介入

当前 PR 超出了自动审查的安全范围，本次不会自动合并到 dev。

1. 文件 background.js 的 diff 长度为 29042，超过单文件限制 AI_REVIEW_MAX_PATCH_CHARS_PER_FILE=12000。

本次未执行自动合并。

[QLHazyCoder]

感谢这次提交和对项目的改进思路。

你这次 PR 里关于 Cloudflare 邮箱生成、Duck 获取稳定性优化这些方向，我们这边已经认真看过，并且已经把需要的内容吸收进 dev 分支了。因为当前 dev 分支和你发起 PR 时的代码基础已经有了一些差异，同时我们这边后续又重新确认了实际需求方向，所以在落地时没有直接按原 PR 方案合并，而是做了本地重构和整理。

这次最终落地的大致方向是：

1. 保留了“支持 Cloudflare 生成注册邮箱”的核心思路
2. 保留了 Duck 邮箱获取稳定性增强的部分
3. 将原来依赖 CF Zone ID / Token / Routing API 的实现，调整成了更轻量的“基于 Cloudflare 域名本地生成随机邮箱”方案
4. 同步整理了侧边栏配置、自动运行第三步逻辑，以及 README 说明，避免后续继续积累复杂和陈旧逻辑

也就是说，这个 PR 的核心思路已经被吸收，但最终代码不是直接按原提交原样合并，而是结合当前分支和我们确认后的需求做了重新整理。

再次感谢你对项目做出的贡献，后续如果你还有类似优化思路，也欢迎继续提交。