fix(123_open): fix token refresh

[WangEdward]

client_secret is required for oauth2 endpoint
let refresh_token determine the auth flow

docs: https://123yunpan.yuque.com/org-wiki-123yunpan-muaork/cr6ced/gammzlhe6k4qtwd9

[Copilot]

Pull Request Overview

This PR fixes the token refresh mechanism in the 123_open driver by ensuring client_secret is included in OAuth2 endpoint requests as required by the API documentation.

• Restructures the conditional logic to require both ClientID and ClientSecret before attempting token operations
• Adds missing client_secret parameter to the refresh token request
• Reorders the token acquisition flow to prioritize refresh token usage when available

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[xrgzs]

OpenList 内，只需要提供两种就可以：

1. Client ID + Client Secret：开发者接入
2. Client ID + Refresh Token：第三方挂载应用接入（使用回调）

对于下面这两种，一般不会出现

3. Client ID + Client Secret + Refresh Token
4. Client ID + Client Secret + Code

因为第三方挂载应用接入的 Client Secret 通常不会公开，只会放到 OpenList-APIPages 上，而且一般申请不到，OpenListTeam不满足资质认证，不会主动对接

另外，第 2 种的 Refresh Token 也能一直刷新

因此，保留原始逻辑即可

[WangEdward]

@xrgzs 我理解，这个 pr 主要解决的问题是原来只要填写了 Client Secret 就无法进入第三方挂载应用接入的刷新逻辑（即使有填 Refresh Token），修改后用 Refresh Token 区分刷新逻辑比较可靠。

---

2. Client ID + Refresh Token：第三方挂载应用接入（使用回调）

这个按照目前 123 的逻辑确实就是足够了

对于下面这两种，一般不会出现

3. Client ID + Client Secret + Refresh Token

这个我认为无论是按照 123 的文档 还是 oauth 的文档 都有提到传递 Client Secret；并且按照一些通用的底层包 Go / Swift 都是如果有提供就传递 Client Secret，按照现在这个实现应该比较稳妥

[xrgzs]

LGTM