OAuth 取 token 的重试预算太短且只覆盖 refresh，长任务遇瞬时故障直接断

[dhnihaoya]

问题

跑长任务时，如果 OAuth 主机短暂不可达（网络抖动、DNS 抽风），取 token 会失败、任务等于断了。现有的重试覆盖对常见的瞬时故障来说太薄。

相关报错（同 #2786）：

[internal] OAuth request to https://auth.kimi.com/api/oauth/token failed:
fetch failed: Connect Timeout Error (attempted address: auth.kimi.com:443,
timeout: 10000ms)

#2786 已经让这类失败被正确归类成可重试的 provider.connection_error（不再塌成 [internal]），但底层的重试预算本身仍然太短——这是本 issue 要解决的。

证据

三个点叠加：

1. 那个 10s 是 undici 的 connect timeout，不是 OAuth 层的超时。 postForm 设了 AbortSignal.timeout(30_000)（packages/oauth/src/oauth.ts:57,68），但它只在连接建立之后才开始计时。当 TCP/TLS 根本连不上时，undici 自带的 connect timeout（默认 10s）先触发，而 OAuth 层没法配置它。

2. 重试预算小且写死。 只有 refreshAccessToken（packages/oauth/src/oauth.ts:226）对传输层错误重试：maxRetries ?? 3，退避 2^attempt * 1000（1s、2s）。放弃前的最坏耗时 ≈ 10s + 1s + 10s + 2s + 10s ≈ 33s。长任务里，auth 主机不可达超过 ~30s，这一轮就彻底失败。

3. 覆盖不全。 requestDeviceAuthorization（oauth.ts:119）和 pollDeviceToken（oauth.ts:168）直接调 postForm，完全没有重试。登录流程对传输层故障零容错。

refresh 最终失败后，上层把它当可重试连接错误处理（v1 agent-core 里是 retryable: true + GOAL_PROVIDER_CONNECTION_PAUSE，见 agent-core/src/errors/codes.ts:333、agent-core/src/agent/turn/index.ts:1468），停下等恢复，而不是自动续命——所以任务一直停着，等网络恢复并 resume。

期望

希望长任务遇到短暂网络问题能自动撑过去而不是直接断；登录流程对网络抖动也更能扛一点。具体重试几次、超时多少是你们的工程取舍，我就不瞎给数值了。

关联

• OAuth 连接错误显示成 [internal] 而非 provider.connection_error，丢失 retryable 标志和专属暂停原因 #2786 / PR fix(auth): classify OAuth token errors as connection/login, not internal #2788：让这类失败被正确归类为可重试错误（修了分类，没修预算）。
• 重构：把 OAuth 错误分类下沉到 kimi-code-oauth，三处复用 #2787：把 OAuth 错误分类下沉到 oauth 包去重。如果本 issue 改变了 refresh 失败时抛出的错误形状（比如新增"重试耗尽"错误类），建议先做 重构：把 OAuth 错误分类下沉到 kimi-code-oauth，三处复用 #2787 再做本 issue，这样分派表只改一处。