Tracking: expand GrantCredential across cloud services

## Goal

Track service-specific uses of the public `GrantCredential` / `Granter` capability introduced by #801 and merged in #803.

This tracker covers operations where an explicit existing service `Credential` authorizes issuance of another independently usable, bounded, expiring `Credential` in the same service family. The operation may downscope the source authority or transition into another authority domain; strict permission-subset semantics are service-specific and are not part of the core contract.

## Shared contract

Every implementation in this tracker should follow the existing reqsign API pattern:

```text
ProvideCredential + GrantCredential -> Granter
ProvideCredential + SignRequest -> Signer
```

- Bind stable endpoint/account/role configuration and one typed service-specific grant to the concrete granter before constructing `Granter`.
- Consume the source through the existing `ProvideCredential` path; do not change `ProvideCredential` or add a generic granted-credential provider adapter.
- Return the existing service `Credential` with exact expiration semantics so it remains directly consumable by `Signer`.
- Validate the source credential variant and grant before I/O, then reject output that is no longer usable after I/O.
- Cache only source or service-specific intermediary state when required; never cache granted output in core, and partition intermediary caches by authority and source identity.
- Redact source credentials, granted credentials, policies, session keys, and raw credential responses from `Debug` and errors.
- Use `Context` I/O and preserve the crate's native/WASM `MaybeSend` contract.
- Keep existing fixed-configuration `ProvideCredential` implementations as compatibility APIs. They may share request construction and response parsing with a new granter; migration is not required.

## Delivered foundation

- [x] Core `GrantCredential` and `Granter`: #801 / #803
- [x] Azure User Delegation SAS and exact SAS expiration: #750 / #751 / #803
- [x] Azure Shared Key Service SAS with exact signed expiration: #817
- [x] Google server-side Credential Access Boundary exchange: #749 / #805
- [x] Google client-side Credential Access Boundary tokens: #804 / #808

## Service coverage

### AWS

- [x] **AWS STS `AssumeRole`** — `AssumeRoleGrant` and `AssumeRoleGranter` explicitly consume an AWS source credential, reuse shared STS request/response machinery, and preserve `AssumeRoleCredentialProvider` as the fixed-flow compatibility API: #813.
- [x] **AWS S3 Access Grants `GetDataAccess`** — `S3AccessGrantsGranter` binds typed account/Region configuration, target, permission, and privilege semantics and returns an expiration-aware AWS credential: #811.
- [x] **AWS S3 Express `CreateSession`** — `S3ExpressSessionGranter` binds typed directory-bucket, partition, and session-mode configuration while preserving `S3ExpressSessionProvider`: #812. Historical protocol testing is tracked in #594.

These checkboxes mean that the public APIs and deterministic protocol coverage are merged into `main`. All three AWS granters now also have live-service CI paths: `AssumeRoleGranter` and `S3ExpressSessionGranter` execute in the gated jobs repaired by #823, while #830 provisions a real S3 Access Grants environment, calls `GetDataAccess`, and validates the issued credential with STS `GetCallerIdentity`. The trusted PR run and the post-merge `main` run both passed these jobs.

Remaining live-cloud acceptance gaps are separate from implementation completion. Real GCP CAB interoperability from #805 / #808 is still unverified, and #817 retains live Azure HNS acceptance for Service SAS `o` / `p` permissions.

### Remaining service work

- [ ] **Alibaba Cloud RAM STS `AssumeRole`** — reuse the provider added by #724 as service-internal machinery, with typed role/policy parameters and an explicit source credential. #684 tracked broader credential-chain and signing parity.
- [ ] **Tencent Cloud STS** — research and implement the signed `GetFederationToken` or `AssumeRole` flow with typed policy/identity parameters. `AssumeRoleWithWebIdentity` remains a `ProvideCredential` flow because its source is an external identity token, not an existing Tencent credential.
- [ ] **Huawei Cloud IAM agency credentials** — add a granter only for the explicit source-credential-authorized agency/token issuance flow, with exact temporary AK/SK/security-token expiration.
- [ ] **Volcengine STS `AssumeRole` for TOS** — first verify the current public protocol, per-issuance authorization controls, and authoritative expiration fields; then implement a granter if the response can satisfy the `SigningCredential` validity contract. #752 previously grouped STS, metadata credentials, and presign; only the granting portion belongs here.

## Existing issue consolidation

- #804 was the canonical implementation issue for client-side GCP CAB and was closed by #808.
- #685 remains the separate, broader tracker for migrating OpenDAL service authentication into reqsign.
- #748 documents how externally delivered credentials enter the existing `ProvideCredential` path; it is complementary to issuance, not a duplicate.
- #594, #684, and #752 are historical implementation/parity issues whose relevant mechanisms may be reused. They did not deliver the remaining explicit `GrantCredential` APIs listed above.
- #749 and #804 were not duplicates: they covered server-side STS exchange and client-issued CAB tokens, respectively; both are now delivered.

No open duplicate issue was found for the remaining Alibaba Cloud, Tencent Cloud, Huawei Cloud, or Volcengine granting work. Add a dedicated child issue when an item enters implementation, link it here, and keep service-specific protocol decisions in that child.

## Out of scope

- Web identity, OIDC, Google external account/WIF, IMDS/ECS/GCE metadata, profile/config loading, and default credential chains; these remain `ProvideCredential` capabilities.
- Presigned requests, POST policies, and other request-bound artifacts; these remain `SignRequest` capabilities.
- A cross-cloud scope/permission model, a second grant generic on `Granter`, a generic output envelope, or automatic insertion into default credential chains.
- Rewriting an existing fixed-flow provider solely to use `Granter` when no explicit issuance API is needed.

Start with the existing GrantCredential/Granter API and the relevant service's current credential provider, such as the Alibaba provider from #724. For a selected remaining cloud, verify its grant protocol, source-credential requirements, and authoritative expiration fields before creating a dedicated child issue. Done means the child issue defines one service-specific implementation and its protocol decisions, tests, and acceptance criteria.

Written by the indexing model from the issue text.