Support Azure user-bound user delegation SAS (sduoid) for principal-bound credential vending

### Is your feature request related to a problem? Please describe.

Polaris currently generates Azure user delegation SAS tokens using the server workload identity\. Consequently, `skoid` identifies the Polaris workload—not the authenticated end user\.

Additionally, [`[AzureStorageCredentialCacheKey](https://github.com/apache/polaris/blob/main/polaris-core/src/main/java/org/apache/polaris/core/storage/azure/AzureStorageCredentialCacheKey.java)`](https://github.com/apache/polaris/blob/main/polaris-core/src/main/java/org/apache/polaris/core/storage/azure/AzureStorageCredentialCacheKey.java) excludes the principal and credential\-vending context\. Multiple users can therefore receive the same cached SAS when scope and permissions match\.

This makes it difficult to reliably determine which authenticated user accessed data and leaves a copied SAS usable by another party\.

### Describe the solution you'd like

Add optional support for Azure user-bound user delegation SAS:

• Obtain the end user’s stable Entra oid and tid from configurable OIDC claims.
• Generate SAS with sv=2025-07-05 or later and sduoid=.
• Support skdutid where cross-tenant delegation is explicitly enabled.
• Add the principal to the Azure credential cache key.
• Add a unique scid and log it together with principal, resource, permissions and expiry—never the complete SAS.
• Keep the feature disabled by default and document the required client support.

With sduoid, Azure requires the storage request to contain a matching Entra bearer token. A copied SAS can therefore not be used by another identity.

### Describe alternatives you've considered

* Restricting the SAS lifetime and resource scope limits the impact of a leaked token. However, anyone possessing the SAS can still use it until it expires.
* Adding scid allows Azure Storage requests to be correlated with the Polaris event that issued the SAS. However, it does not verify that the caller is the intended user.
* Client-managed IAM without credential vending is covered by [#5050](https://github.com/apache/polaris/issues/5050)⁠, but removes Polaris-managed storage subscoping.
* Azure credential path subscoping is tracked in [#1801](https://github.com/apache/polaris/issues/1801)⁠, but does not provide user binding.

### Additional context

I am aware that Azure user\-bound user delegation SAS is currently **in preview**\. Nevertheless, it is extremely valuable for traceability, incident response and regulated multi\-user environments because it combines:

1. a SAS issued for a specific authenticated user,
2. enforced proof of that user’s Entra identity at access time, and
3. correlation between Polaris and Azure Storage audit logs\.

Microsoft documentation:

- [User\-bound user delegation SAS](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#user-bound-user-delegation-sas)
- [Signed correlation ID \(](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-correlation-id)[`scid`](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-correlation-id)[\)](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-correlation-id)

Start by reading AzureStorageCredentialCacheKey.java and tracing the Azure credential-vending path that creates and caches user delegation SAS tokens. Define how configurable OIDC claims, principal-aware caching, sduoid/skdutid, scid logging, default-disabled behavior, and client documentation fit together; done includes coverage for these requirements without logging complete SAS values.

Written by the indexing model from the issue text.