Support S3 Express session-token signing for custom authorities

## Context

`S3ExpressSessionGranter::new_with_custom_endpoint` can issue S3 Express session credentials from an explicitly trusted custom HTTPS authority. A client must then use those credentials to sign object requests to the compatible service with `x-amz-s3session-token`.

`RequestSigner` currently selects the session-token representation from the request authority:

```rust
let is_s3_express = !use_standard_session_token
&& (authority.contains("s3express") || authority.contains("--x-s3"));
```

As a result, a session credential used against an ordinary custom authority such as `https://objects.example.com` is signed with `x-amz-security-token`. The custom `CreateSession` path therefore cannot be consumed correctly unless the deployment's hostname happens to match the AWS naming heuristic.

This blocks OpenDAL's explicit `enable_s3_express_session_auth` compatibility path for trusted custom endpoints.

## Expected contract

Provide an explicit or service-derived way to select the S3 Express session-token representation independent of the request hostname.

One possible contract is:

- `RequestSigner::new("s3express", region)` uses `x-amz-s3session-token` and `X-Amz-S3session-Token` for every authority by default.
- `with_standard_session_token()` continues to select `x-amz-security-token` and `X-Amz-Security-Token` for IAM-authenticated exceptions such as `CopyObject`, `HeadBucket`, and `UploadPartCopy`.
- Other AWS services retain the standard session-token representation.

The exact API shape can differ, but callers must not need to encode protocol semantics into a trusted custom hostname.

## Acceptance criteria

- A session credential signs header-authenticated requests to an arbitrary custom authority with `x-amz-s3session-token`.
- Query authentication uses `X-Amz-S3session-Token` for the same path.
- `with_standard_session_token()` still produces the standard IAM token representation on S3 Express endpoints and custom authorities.
- Existing AWS directory-bucket signing remains unchanged.
- Tests cover both AWS-derived and custom authorities without exposing token material in errors or debug output.

Related to #836 and #838.

Start by reading RequestSigner and S3ExpressSessionGranter::new_with_custom_endpoint, then trace the existing authority-based token selection and related signer tests. Done means header and query authentication use the S3 Express token for arbitrary custom authorities, standard-token overrides still work, AWS directory-bucket signing is unchanged, and tests cover both authority types without exposing token material.

Written by the indexing model from the issue text.