feat: support SUB2API mode for OAuth generation and callback verification

[hisence999]

概述

这个 PR 为现有 Chrome 扩展新增了 SUB2API 模式，让 OAuth 链接获取和回调验证不再只能依赖 CPA 面板，也可以直接对接 SUB2API 后台完成整条链路。

支持的功能

• 在侧边栏新增 来源模式切换：CPA 面板 / SUB2API
• 在 SUB2API 模式下支持配置：
  • 后台地址
  • 登录邮箱
  • 登录密码
  • 分组名（默认 codex）
  • 回调地址（默认 http://localhost:1455/auth/callback）
• Step 1 支持从 SUB2API 生成最新的 OpenAI OAuth 授权链接
• Step 6 刷新登录链接时，会按当前模式重新生成对应来源的 OAuth URL
• Step 9 支持将 localhost 回调提交到 SUB2API，自动完成：
  • 授权码交换
  • 在目标分组下创建账号
• SUB2API 创建账号时，优先使用当前流程邮箱作为账号名称，便于后台识别和后续排查
• 保持原有 CPA 流程不变，已有用户可继续使用原工作流

实现方式

1. 侧边栏配置扩展

在 sidepanel/sidepanel.html 和 sidepanel/sidepanel.js 中新增来源选择与 SUB2API 配置项：

• panelMode
• sub2apiUrl
• sub2apiEmail
• sub2apiPassword
• sub2apiGroupName
• sub2apiRedirectUri

界面会根据当前来源动态切换显示字段，并同步更新 Step 9 的按钮文案。

2. 后台编排分支化

在 background.js 中把 Step 1 / Step 9 逻辑按来源拆成两条分支：

• executeCpaStep1 / executeCpaStep9
• executeSub2ApiStep1 / executeSub2ApiStep9

这样保留了原来的 CPA 实现，同时让 SUB2API 逻辑独立维护，不会污染现有流程。

另外还增加了 SUB2API 相关运行时状态存储：

• sub2apiSessionId
• sub2apiOAuthState
• sub2apiGroupId
• sub2apiDraftName

用于在 Step 1 和 Step 9 之间传递授权会话信息。

3. 新增 SUB2API 页面脚本

新增 content/sub2api-panel.js，负责在真实浏览器标签页环境中完成 SUB2API 侧的处理。

Step 1 的实现：

1. 登录 SUB2API 后台
2. 查询目标分组（默认 codex）
3. 调用 OpenAI Auth 生成接口
4. 读取 auth_url / session_id
5. 从 auth_url 中解析并保存 state
6. 回传给后台继续后续 OAuth 流程

Step 9 的实现：

1. 解析 localhost 回调中的 code / state
2. 校验回调 state 与 Step 1 保存的 state 一致
3. 调用 SUB2API 的 OpenAI code exchange 接口
4. 用交换结果组装 platform=openai、type=oauth 的账号数据
5. 调用账号创建接口，把账号绑定到目标分组

4. 对接的 SUB2API 接口

本 PR 实际对接的是 OpenAI Auth 这套接口，而不是 antigravity：

• POST /api/v1/auth/login
• GET /api/v1/admin/groups/all
• POST /api/v1/admin/openai/generate-auth-url
• POST /api/v1/admin/openai/exchange-code
• POST /api/v1/admin/accounts

这能确保实现与 SUB2API 后台当前实际的 OpenAI Auth 流程一致。

兼容性与影响范围

• 不影响原有 CPA 模式
• 不改动步骤 2~8 的 OpenAI 页面自动化逻辑
• 只在 Step 1 / Step 6 / Step 9 的 OAuth 来源与回调提交环节做模式分流

测试要点

已重点验证以下链路：

• CPA 模式仍可继续使用
• SUB2API 模式下可以成功生成 OAuth URL
• Step 6 可以按来源刷新 OAuth URL
• Step 9 可以解析 localhost 回调并走 SUB2API 的 OpenAI exchange/create 逻辑
• 新建账号名称会优先取当前流程邮箱

[github-actions]

AI 审查需要人工介入

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

1. 文件 background.js 的 diff 长度为 12311，超过单文件限制 AI_REVIEW_MAX_PATCH_CHARS_PER_FILE=12000。
2. 文件 content/sub2api-panel.js 的 diff 长度为 12233，超过单文件限制 AI_REVIEW_MAX_PATCH_CHARS_PER_FILE=12000。

本次未执行自动合并。

[hisence999]

小BUG，上传的账号没有自动填入模型、优先级、并发字段，导致可能不能被调用，可以手动修改一下，稍后我在提交个PR把，把这些默认配置补全。

[yanye666]

支持，感觉还是sub2api好用点

[QLHazyCoder]

codex-gpt-5.4分析结果（不一定完全正确，请佬友确认无问题下面继续评论）：

我这边结合 PR diff 和仓库现有逻辑看了一遍，整体上把 Step 1 / Step 9 按 CPA / SUB2API 拆分的思路是合理的，原有 CPA 流程也基本保留住了；不过现在我认为还有两个点需要先确认，不然直接合可能会埋坑：

1. SUB2API 的“回调地址可配置”目前和实际实现不一致。Step 1 虽然允许填写自定义回调地址，但 Step 8 捕获回调、Step 9 校验回调时都还是只接受 localhost / 127.0.0.1，所以如果这里真的改成别的主机名，前面能生成 OAuth URL，后面流程还是会直接失败。现在这块更像是“端口可配”，不是“完整回调地址可配”。

2. SUB2API 的 Step 1 / Step 9 走的是内容脚本消息链路，但后台这里还是按默认 30 秒响应超时处理，而且超时会被当成 retryable。Step 9 这边要登录、exchange code、再创建账号，如果接口慢一点超过 30 秒，后台有机会把同一个步骤重新发一次，最坏情况会重复创建账号。

另外我看 GitHub 当前给这个 PR 的状态还是 mergeable=CONFLICTING，说明和现在的 dev 也已经有冲突了，这个最好一起处理掉。

如果上面两个点你那边已经有额外前提（比如回调地址虽然可填，但业务上只允许 localhost；或者 SUB2API 接口一定会在 30 秒内返回），那可以直接说一下；否则我建议先把这两个问题收掉再继续推进。

[hisence999]

(1)已经固定localhost回调地址。（2）上传账号自动携带必要默认配置。（3）AI自动审查DIFF超过WORKFLOW工作流限制，需要人工审核。（4）本地已无冲突。希望佬友审核一下。

[QLHazyCoder]

感谢贡献这次改动，SUB2API 模式的核心思路和主体实现已经吸收进 dev 了。我这边顺手处理了和当前 dev 的冲突，并补了一个 SUB2API 步骤执行超时后可能重复触发的问题，后续如果你还有类似改进也欢迎继续提交。