[doc](lance) Document OSS support for the Lance catalog

[FANNG1]

Summary

Documents the Alibaba Cloud OSS support added by apache/doris#67157 (issue apache/doris#67131). The Lance catalog page currently tells users that a warehouse can only be a local path, file:// or s3://, so OSS looks unsupported.

Requested by @zhangstar333 in apache/doris#67157.

Changes

Both versioned_docs/version-4.x/.../lance-catalog.mdx and the zh-CN copy:

• warehouse now lists oss:// among the accepted forms.
• New Use Alibaba Cloud OSS section next to the existing S3 one, with a CREATE CATALOG example, the qualified oss://bucket.oss-<region>.aliyuncs.com/path form Doris reduces to the bucket, the bucket requirement, and a note on oss.session_token.
• REST catalog section now names the OSS properties usable as defaults, states that namespace-vended credentials take precedence over the catalog's own, and shows a catalog created with no access key at all.
• Documents that a namespace may vend the options as either oss_endpoint / oss_access_key_id / oss_secret_access_key / oss_region / oss_security_token or the bare OSS-native endpoint / access_key_id / access_key_secret / region / security_token, and that vending one option under both spellings with different values is an error.

Verification

The examples were run against a real OSS bucket on a Doris cluster built from apache/doris#67157, not written from the code alone:

• the filesystem example exactly as written — without fs.oss.support, which the doc does not mention — creates the catalog and scans correctly;
• the qualified oss://bucket.<endpoint>/path warehouse also scans, and oss:/path is rejected at CREATE CATALOG;
• the no-credential REST example was exercised against a real Apache Gravitino 1.3.0 lance-rest service, which vends the bare OSS-native spellings;
• the conflicting-spelling error was reproduced.

Scope

Every statement on the page was exercised against a live bucket, including oss.session_token: an STS triple obtained through AssumeRole scans the table, and the same temporary key pair without the token fails to initialize the catalog with OSS's own InvalidAccessKeyId / "The Security Token may be lost to specify that it is a STS Access Id". That negative control is what shows the token is carried through to the BE rather than the scan succeeding by some other route.

A path-style addressing note was written and then removed: Alibaba Cloud OSS uses virtual-hosted addressing and its public endpoints no longer accept path-style requests, so there was no configuration to confirm it against.