OAuth 连接错误显示成 [internal] 而非 provider.connection_error，丢失 retryable 标志和专属暂停原因

问题

OAuth 获取 token 时遇到连接失败，用户侧看到的是：

[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)

[internal] 这个标签是错的。按设计，OAuthConnectionError 应该被映射成 provider.connection_error（可重试、带专门的暂停原因），但实际到达 UI 时被归类成了 internal。

证据

• 映射逻辑是存在的：mapOAuthTokenError（packages/node-sdk/src/oauth-error.ts:25）把 OAuthConnectionError / RetryableRefreshError 映射成 PROVIDER_CONNECTION_ERROR，packages/node-sdk/src/auth.ts:260-279 里的包装版 token provider 会应用这个映射。
• 但 [internal] 是兜底错误码（packages/agent-core/src/errors/serialize.ts:141），TUI 用 [${error.code}] 渲染（apps/kimi-code/src/tui/utils/event-payload.ts:112）。出现 [internal] 说明错误是被当成普通 Error 序列化的——也就是说这条路径绕过了映射。
• provider.connection_error 本身 retryable: true（packages/agent-core/src/errors/codes.ts:333），并且会得到专门的 GOAL_PROVIDER_CONNECTION_PAUSE 暂停原因（agent-core/src/agent/turn/index.ts:1468）。被误判成 internal 后，goal 会落到兜底的 GOAL_RUNTIME_PAUSE（第 1486 行），retryable 信号也丢了。

可能原因（待确认）

任务运行中途触发的 token 刷新，似乎没有走应用 mapOAuthTokenError 的 resolveOAuthTokenProvider 包装层，导致 OAuthConnectionError 以原始形态冒泡上来。需要确认长任务刷新路径里到底是哪个调用点绕过了包装（也可能是这段映射逻辑是后加的、用户的版本还没带上）。

期望

任务运行中遇到 OAuth 连接失败时，应当以 provider.connection_error、retryable: true、带连接专属暂停原因的形式呈现，而不是 [internal]。

Trace the long-running token refresh path from packages/node-sdk/src/auth.ts:260-279 and compare it with mapOAuthTokenError in packages/node-sdk/src/oauth-error.ts:25. Check where the error reaches packages/agent-core/src/errors/serialize.ts:141 and how the pause is selected in packages/agent-core/src/agent/turn/index.ts:1468. Done means an OAuth connection failure reaches the UI as provider.connection_error with retryable true and the provider-specific pause reason instead of internal.