fix(drivers/115_open): refresh OSS STS token during multipart upload

[CloudCauldron]

Summary / 摘要

The 115 Open driver's multpartUpload obtained the Aliyun OSS STS token once and created the OSS client a single time, never refreshing it during the upload. The STS token expires in ~1 hour, so any single-file upload whose upload phase runs past that window (large files and/or a throttled source) failed with oss: SecurityTokenExpired and then InvalidAccessKeyId, aborting the transfer.

This refreshes the token after 45 minutes (safe margin under the ~1h lifetime): it calls UploadGetToken again and rebuilds the OSS client/bucket with the new credentials, reusing the same multipart upload session (imur) to continue uploading the remaining parts. The multipart session is identified by bucket + object + uploadId and is not bound to the credentials, so switching credentials mid-upload is valid.

• User-visible: large/slow uploads to 115 (e.g. relaying multi-GB files from a rate-limited source) that previously failed mid-way now complete.
• Implementation: a per-part elapsed-time check + a token-refresh closure. No public API / config / storage changes.

Note: the cookie-based driver drivers/115/util.go UploadByMultipart has an analogous bug — it refreshes ossToken on a 50-minute ticker but never rebuilds ossClient/bucket, so requests are still signed with the stale AccessKeyId → InvalidAccessKeyId. Left unchanged here to keep this PR focused and validated; happy to follow up in a separate PR.

• This PR has breaking changes.
• This PR changes public API, config, storage format, or migration behavior.
• This PR requires corresponding changes in related repositories.

Related repository PRs / 关联仓库 PR:

• OpenList-Frontend:
• OpenList-Docs:

Related Issues / 关联 Issue

N/A — direct fix, no separate tracking issue.

Testing / 测试

• go test ./... (未运行完整测试套件)
• go build ./drivers/115_open/ and go vet ./drivers/115_open/ pass
• Manual test: built a local image containing this change and ran a real 百度→115 relay of several ≥4GB files whose upload phase exceeded 50 minutes (source throttled to ~700 KiB/s). Before this change the uploads failed around the 50-minute mark with SecurityTokenExpired → InvalidAccessKeyId; after it, the token is refreshed at 45 minutes and the transfers complete successfully.

Checklist / 检查清单

• I have read CONTRIBUTING.
• I confirm this contribution follows the repository license, contribution policy, and code of conduct.
• I have formatted the changed code with gofmt.
• I have requested review from relevant maintainers or code owners where applicable.

AI Disclosure / AI 使用声明

• This PR includes AI-assisted content.

Tools used / 使用工具:

• Claude (Claude Opus 4.8)

Usage scope / 使用范围:

• Code generation / 代码生成

• Review assistance / 审查辅助

• I have reviewed and validated all AI-assisted content included in this PR.

• I have ensured that all AI-assisted commits include Co-Authored-By attribution.

• I can reproduce all AI-assisted content included in this PR without any AI tools.

[xrgzs]

When uploading multiple files at the same time, is locking required to prevent race condition?

[CloudCauldron]

I don't think an extra lock is needed.

The mutable state changed by the refresh logic (bucket, tokenObtained, and the refreshOSSToken closure) is local to one multpartUpload call. Each concurrent file upload enters Put separately, gets its own UploadInit response, OSS token, OSS client/bucket, multipart upload session (imur), and parts slice.

Within a single multipart upload, parts are uploaded sequentially in the loop; retry.Do is synchronous and no goroutine shares bucket while it can be replaced. So refreshing the token only affects the current upload's local bucket handle.