feat: Enhance login flow with add-email and phone verification support

- Added support for the add-email page in the logging status module.
- Updated step 8 to handle phone-registered accounts during email verification.
- Implemented logic to submit add-email before polling for email verification codes.
- Enhanced tests for step 7 to detect username input as phone number and ignore hidden inputs.
- Improved step 8 to allow add-email handoff only when requested.
- Updated documentation to reflect changes in the login verification flow.

项目完整链路说明.md

@@ -366,9 +366,9 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功
 
 这两步共享验证码主流程：
 
-1. 先按账号身份分流验证码通道：
+1. 先按注册阶段或认证页真实状态分流验证码通道：
    Step 4：邮箱注册走邮箱验证码，手机号注册走短信验证码
-   Step 8：邮箱登录走邮箱验证码，手机号登录走短信验证码
+   Step 8：真实邮箱验证码页走邮箱验证码，真实手机验证码页才走短信验证码；如果先进入 `add-email`，先绑定邮箱再走邮箱验证码
 2. 确定 provider
 3. 必要时重发验证码
 4. 轮询邮箱、短信 API 或对应 provider 通道
@@ -438,7 +438,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功
    - 邮箱账号：沿用现有邮箱登录链路
    - 手机号账号：优先探测登录页是否存在手机号登录入口，必要时展开更多选项或从邮箱页切到手机号页；进入手机号输入页后会复用 Step 2 的可视国家下拉框同步逻辑，按本轮手机号最长区号切到目标国家，填写后还会读回输入框确认已包含本地号码，避免英国 `+44` 号码仍按默认澳大利亚 `+61` 提交或只提交区号
 4. 登录；如果进入密码页且当前有密码，则填写并提交密码；如果当前没有密码但检测到一次性验证码入口，则直接切换到一次性验证码登录
-5. 确保真正进入验证码页；手机号登录允许以 `phone-verification` 作为 Step 7 的成功落点
+5. 确保真正进入验证码页或登录后续页；手机号登录允许以 `phone-verification` 作为 Step 7 的成功落点，手机号注册后的 OAuth 登录也允许以真实 `add-email` 作为 Step 7 完成并交给 Step 8 接管
 6. 如果页面没有可用的手机号登录入口，则 Step 7 直接抛出明确业务错误，不再误进入 Step 8 邮箱轮询
 7. 如果未进入验证码页，则按可恢复逻辑最多重试 3 次；但一旦当前失败已经明确进入 `https://auth.openai.com/add-phone`，则立即退出步骤 7 内部重试，不再继续第 2 / 3 次尝试
 8. 自动运行一旦进入步骤 7 之后的链路，若后续步骤报错且认证页未进入 `https://auth.openai.com/add-phone`，则统一回到步骤 7 重新开始授权流程
@@ -457,19 +457,21 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功
 
 流程：
 
-1. 先按账号身份判断当前登录验证码通道
-2. 邮箱账号：
-   - 确认当前认证页已经进入邮箱验证码页
+1. 先确认当前认证页真实状态，而不是只看 `accountIdentifierType`。
+2. 当前是 `add-email`：
+   - 调用 `resolveSignupEmailForFlow` 获取或生成本轮绑定邮箱
+   - 内容脚本发送 `SUBMIT_ADD_EMAIL` 填写邮箱并提交
+   - 页面进入邮箱验证码页后，用绑定邮箱作为 `step8VerificationTargetEmail`
+3. 当前是邮箱验证码页：
    - 对非 2925 provider，固定当前验证码页显示邮箱为本次 Step 8 的目标邮箱
    - 打开邮箱页或 API 轮询入口
    - 轮询登录验证码并回填
-3. 手机号账号：
-   - 直接复用注册成功后的同一手机号订单，不重新申请新号码
-   - 重新激活该号码，轮询短信验证码
+4. 当前是真实 `phone-verification` 页：
+   - 才复用手机号验证码共享流程，重新激活同一号码并轮询短信验证码
    - 在当前 `phone-verification` 页回填短信验证码
-4. 如果登录验证码提交后页面进入 `add-phone / 手机号页`，则步骤 8 会保留“登录验证码已提交成功”的结果，并把后续手机号验证需求继续交给步骤 9 处理
-5. 如遇邮箱轮询类失败或显式的 `STEP8_RESTART_STEP7` 恢复错误，则按有限次数回到 Step 7 重试
-6. 获取到登录验证码后不再触发“刷新 OAuth 并重走 Step 7”的前置回放，直接在当前验证码页提交并继续进入 Step 9
+5. 如果登录验证码提交后页面进入 `add-phone / 手机号页`，则邮箱注册模式下交给后续 OAuth 后置手机号验证链路；手机号注册模式不把 `signupPhone*` 身份误当成官方 add-phone 订单
+6. 如遇邮箱轮询类失败或显式的 `STEP8_RESTART_STEP7` 恢复错误，则按有限次数回到 Step 7 重试；若仍停在验证码页、手机验证码页或 add-email 页，则优先在当前链路重试
+7. 获取到登录验证码后不再触发“刷新 OAuth 并重走 Step 7”的前置回放，直接在当前验证码页提交并继续进入 Step 9
 
 补充：
 
@@ -477,7 +479,8 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功
 - 对 `2925 receive` 而言，Step 8 会把当前目标注册邮箱一并传给 2925 内容脚本；只有当邮件里显式写出了其他邮箱时才会跳过，从而在不破坏历史兼容性的前提下，尽量降低误收验证码的概率。
 - 对 `custom` provider 而言，Step 8 仍使用手动验证码确认弹窗；弹窗当前额外提供“出现手机号验证”按钮，点击后会直接抛出与真实 `add-phone` 页面一致的 fatal 错误，供 Auto 按既有 add-phone 分支继续下一邮箱。
 - 当登录验证码提交后进入 `phone-verification` 页时，内容脚本会显式把该页面识别为“手机验证码页”，避免与邮箱验证码页混淆。
-- 手机号登录分支不会再读取邮箱 provider 配置，也不会误调用邮箱轮询；如果缺少可复用的注册手机号激活记录，会直接要求回到步骤 7 重新开始登录。
+- 手机号注册身份本身不会让 Step 8 自动走短信；只有真实页面状态是 `phone_verification_page` 时才调用短信 helper。手机号注册登录后出现 `add-email` 时，Step 8 走“绑定邮箱 -> 邮箱验证码”链路。
+- `email_in_use` 会在 Step 8 当前步骤内清理当前邮箱并重新打开 `add-email` 获取新邮箱；`max_check_attempts` 不继续点击认证页 `重试`，只恢复当前 Step 8。
 
 ### Step 9