fix: allow manual retry of invalid Build credentials

[chenyme]

概要

• 允许管理员手动刷新已失效的 Grok Build 凭据，并强制向 OAuth 上游请求一次。
• 单账号刷新、批量刷新和“刷新全部”均支持失效账号重试。
• 自动调度、网关 401 恢复和正常选号仍会拦截永久失效凭据，避免无效请求循环。
• 保留完整的凭据刷新错误诊断，包括 HTTP 状态、错误码、错误信息和额外详情。

背景

Grok Build 账号一旦因 invalid_grant 等错误被标记为永久失效，原逻辑会直接阻止后续刷新。

这对自动任务是合理的，但也导致管理员点击手动刷新时无法真正请求上游。即使 Refresh Token 已在上游恢复，或此前状态判断已经过时，也只能继续看到旧错误。

修改内容

手动强制重试

以下管理员操作会绕过永久失败状态一次：

• 单账号刷新凭据
• 选中账号批量刷新
• 刷新全部凭据

具备 Refresh Token 的启用账号都会参与刷新，包括状态为“失效”的账号；缺少 Refresh Token、已停用或 Provider 不支持刷新的账号仍会跳过。

自动链路保持保护

以下链路不会绕过永久失败状态：

• 后台凭据刷新调度
• 临界凭据恢复
• Gateway 请求过程中的凭据续期
• 正常账号选号与调用

因此不会因为本次修改持续请求已经确认失效的 Refresh Token。

并发隔离

手动重试使用独立的 singleflight 标识，与自动刷新任务隔离，同时继续复用账号级分布式锁，避免多实例重复刷新。

状态处理

• 刷新成功：更新 Token，恢复账号为可用状态，并清除历史刷新错误。
• 刷新失败：保存本次上游返回的最新状态和错误信息。
• 手动重试产生的临时错误不会继承旧的永久失败标记。
• 自动链路仍保留既有永久失败状态，防止错误降级。

用户影响

管理员可以通过手动刷新验证失效凭据是否已经恢复，无需重新导入账号。

自动任务的保护行为保持不变，不会增加永久失效凭据的后台请求压力。

验证

go test ./... -count=1
go test -race ./internal/application/account ./internal/application/gateway -count=1
pnpm lint
pnpm build
git diff --cached --check

以上检查全部通过。