[Bug] SDK OSS upload/download fails with 403 AccessDenied after admin advertises `Bucket`/`Prefix` (SDK ≥ 1.8)

## Summary

ROCK SDK ≥ 1.8 (both Python and TypeScript) can fail with `403 AccessDenied` when uploading or downloading files through OSS, even though the STS credentials returned by the admin are valid. The root cause is a two-layer mismatch between what the SDK uses to talk to OSS and what the primary-account STS token is actually allowed to do.

## Reproduction

Environment:

- Admin version: any release where `/get_token?account=primary` returns the full `Bucket` / `Endpoint` / `Region` / `Prefix` fields (`6e8549ca6` 2026-05-15 onwards).
- SDK version: `rock>=1.8` (Python) or `@alibaba/rock-sdk` Unreleased (TypeScript).
- Worker / client host has any of these legacy env vars set:
- `ROCK_OSS_BUCKET_NAME=xrl-sandbox`
- `ROCK_OSS_BUCKET_ENDPOINT=...`
- `ROCK_OSS_BUCKET_REGION=...`
- Admin is configured to use the **primary** account (`chatos-rock`).

Steps:

1. Run any SDK code that triggers an OSS-backed transfer, e.g. `await sandbox.fs.upload_file("./big.tar.gz", "/workspace/big.tar.gz")`.
2. SDK calls `/get_token` with no query param → admin defaults to `legacy` → returns STS for `xrl-sandbox`.
3. SDK reads `ROCK_OSS_BUCKET_NAME=xrl-sandbox` from env and signs requests against `xrl-sandbox`.
4. But admin is actually using the **primary** account (`chatos-rock`), so the `legacy` STS token is not authorized for the bucket the server expects.

Symptom: `403 AccessDenied` from OSS.

## Secondary failure (TS SDK only)

Even after fixing the bucket mismatch, TS SDK still fails with `403 AccessDenied` on the actual `PutObject` / `GetObject` because:

- Primary-account STS tokens carry a RAM policy that only permits writes under a fixed prefix (typically `rock-transfer/`).
- TS SDK's `uploadViaOss` / `downloadViaOss` build the object key from `${timestamp}-${fileName}` and write to the **bucket root**, e.g. `oss://chatos-rock/1700000000-foo.tar.gz`.
- This is rejected by the RAM policy.
- Python SDK was already correct here (`OssClient._compute_object_name` prepends `client_config.prefix`); TS SDK was lagging.

## Root cause

Two independent layers were "env-first" rather than "server-first":

1. **Bucket / endpoint / region resolution.** SDK ≥ 1.8 was supposed to take its OSS config from the admin response, but the code path was still reading `ROCK_OSS_BUCKET_*` env vars first and only falling back to the server when env was missing. Stale env from earlier deployments silently overrode the server.
2. **Object key path.** TS SDK never prepended the server-advertised `Prefix` to the OSS object key, so even when bucket resolution was correct, the RAM policy on primary-account STS tokens rejected writes to the bucket root.

The contract between admin and SDK is: **admin is the source of truth for OSS configuration; env vars are a compatibility fallback for older admin builds that don't advertise the full config.**

## Expected behavior

- When admin returns a complete OSS config (`Bucket`, `Endpoint`, `Region`, optional `Prefix`), SDK uses it verbatim.
- Env vars are consulted only when the server response is incomplete.
- `getOssStsCredentials()` requests `?account=primary` explicitly, so the STS token always matches the bucket the server advertises.
- All OSS object keys are prefixed by `ossConfig.prefix` (when set), matching the RAM policy attached to the STS token.

## Impact

- All clusters where admin uses the primary account (`chatos-rock`) AND worker/client hosts still carry legacy `ROCK_OSS_BUCKET_*` env vars are affected.
- Affects both `sandbox.fs.upload_file` / `download_file` and any TS SDK flow that lands in `uploadViaOss` / `downloadViaOss`.
- No data loss; transfers just fail with 403 until env is cleaned or the fix lands.

## Workarounds

- Unset `ROCK_OSS_BUCKET_NAME` / `ROCK_OSS_BUCKET_ENDPOINT` / `ROCK_OSS_BUCKET_REGION` on the affected hosts. (TS SDK still hits the prefix bug.)

## Proposed fix

See the linked PR — server-first resolution in both SDKs, plus prefix-aware object name builder in TS SDK that mirrors Python's `OssClient._compute_object_name`. SDK-only change; no admin changes required (the admin contract was already correct since `6e8549ca6`).

## Versions

- SDK (Python): `>=1.8`
- SDK (TS): Unreleased (current `master`)
- Admin: any version that returns `Bucket`/`Endpoint`/`Region` from `/get_token?account=primary` (≥ `6e8549ca6`, 2026-05-15)

Start by tracing getOssStsCredentials() and the OSS configuration resolution in both SDKs, then compare the TypeScript uploadViaOss/downloadViaOss paths with Python's OssClient._compute_object_name. Verify server-provided Bucket, Endpoint, Region, and Prefix take precedence, with environment variables only as fallback; run the affected upload and download flows and confirm keys use the advertised prefix.

Written by the indexing model from the issue text.