重构：把 OAuth 错误分类下沉到 kimi-code-oauth，三处复用

背景

修复 #2786 时，把"OAuth 取 token 失败 → 公开错误码"的分类逻辑接到了两个 facade：

• packages/node-sdk/src/oauth-error.ts mapOAuthTokenError（既有）
• packages/agent-core/src/services/auth/managedAuth.ts mapOAuthTokenError（本次新增）
• packages/agent-core-v2/src/app/auth/authService.ts classifyOAuthTokenError（本次新增）

三处的 instanceof 匹配逻辑几乎逐字相同：

OAuthUnauthorizedError            → auth.login_required
OAuthConnectionError | RetryableRefreshError → provider.connection_error
其余                              → 原样抛

差异只在最终错误类型不同（KimiError vs Error2）和对应错误码常量不同——但"哪个 oauth 错误类属于哪一类"这张映射表是同一份，且后续若 oauth 包新增一个可重试错误类，三处都得同步改。

建议

把分类下沉到 @moonshot-ai/kimi-code-oauth（三处都已经依赖它，且 oauth 包本身最清楚自己每个错误类的语义，不算越界）。新增一个纯分类函数，例如：

export type OAuthErrorCategory = 'unauthorized' | 'connection';
export function classifyOAuthError(error: unknown): OAuthErrorCategory | undefined;

三个消费者各自只保留"类别 → 自己的错误类型"的薄封装（这一步因为 KimiError / Error2 分属不同包，无法再合并）。这样 instanceof 列表只维护一份。

为什么没在 #2786 的 PR 里直接做

那次修复聚焦 bug 本身（oauth 传输失败塌成 [internal]），且范围明确限定不动 node-sdk。下沉会扩成 4 包改动，独立做审核更清晰。

Start by comparing the three existing mappings in packages/node-sdk/src/oauth-error.ts, packages/agent-core/src/services/auth/managedAuth.ts, and packages/agent-core-v2/src/app/auth/authService.ts. Then inspect the @moonshot-ai/kimi-code-oauth package entry points and its OAuth error classes. Done means one shared classifyOAuthError mapping is used by all three consumers while each retains its own category-to-error wrapper.