Key Vault challenge-based authentication fails to extract tenant ID from DSTSv2 authority URIs

# Key Vault challenge-based authentication fails to extract tenant ID from DSTSv2 authority URIs

## Summary

The Key Vault challenge-based authentication policy incorrectly parses the tenant ID from `WWW-Authenticate` challenge responses when the authorization URI uses a DSTSv2 (Distributed Security Token Service v2) authority format. This causes authentication failures when connecting to Key Vault endpoints that return DSTSv2 challenges.

## Background

When a Key Vault client makes an unauthenticated request, the service responds with a `401 Unauthorized` containing a `WWW-Authenticate` header like:

```
Bearer authorization="https://login.microsoftonline.com/{tenantId}", resource="https://vault.azure.net"
```

The client parses the `authorization` URI to extract the tenant ID (typically the first path segment) and uses it to acquire a token.

## The Bug

The current implementation assumes the tenant ID is always the **first path segment** of the authorization URI. This is correct for standard Entra ID (AAD) authorities:

```
https://login.microsoftonline.com/{tenantId}/oauth2/authorize
^^^^^^^^^
Segments[1] = tenantId ✅
```

However, DSTSv2 authority URIs have a **different path layout** where `dstsv2` is the first path segment and the tenant ID is the **second**:

```
https://uswest2-passive-dsts.dsts.core.windows.net/dstsv2/{tenantId}
^^^^^^ ^^^^^^^^^
Seg[1] Seg[2] = tenantId
```

With the current logic, the extracted "tenant ID" is the literal string `dstsv2` instead of the actual GUID, causing token acquisition to fail or target the wrong tenant.

### Example challenge header from a DSTSv2 endpoint

```
Bearer authorization="https://uswest2-passive-dsts.dsts.core.windows.net/dstsv2/de763a21-49f7-4b08-a8e1-52c8fbc103b4", resource="https://foo.bar.core.windows.net"
```

## Expected Behavior

The tenant ID should be correctly extracted as `de763a21-49f7-4b08-a8e1-52c8fbc103b4`, regardless of whether the authority URI is a standard Entra ID endpoint or a DSTSv2 endpoint.

## Fix Description

When parsing the authorization URI to extract the tenant ID:

1. Extract the first path segment as usual.
2. If the first path segment equals `dstsv2` (case-insensitive) **and** there is a subsequent path segment, use that subsequent segment as the tenant ID instead.

### Pseudocode

```
tenantId = authorizationUri.pathSegments[1] // e.g. "dstsv2" or a GUID

if tenantId.equalsIgnoreCase("dstsv2") AND pathSegments.length > 2:
tenantId = authorizationUri.pathSegments[2]
```

## Affected Area

This bug is in the **Key Vault challenge-based authentication policy** — the component that handles the `401 → parse challenge → acquire token → retry` flow. In each language SDK, this is typically:

| Language | Approximate Location |
|----------|---------------------|
| .NET | `ChallengeBasedAuthenticationPolicy.ChallengeParameters` constructor |
| Python | `ChallengeAuthPolicy` / `HttpChallenge` class |
| Java | `KeyVaultCredentialPolicy` |
| JavaScript/TypeScript | `challengeBasedAuthenticationPolicy` / challenge parsing utilities |
| Go | `challengePolicy` / challenge parsing in `azkeys`, `azsecrets`, `azcertificates` |

## Reference Fix

The .NET fix is in [Azure/azure-sdk-for-net#56416](https://github.com/Azure/azure-sdk-for-net/pull/56416).

Key change in `ChallengeBasedAuthenticationPolicy.cs`:

```csharp
TenantId = authorizationUri.Segments[1].Trim('/');
if (TenantId.Equals("dstsv2", StringComparison.OrdinalIgnoreCase) && authorizationUri.Segments.Length > 2)
{
TenantId = authorizationUri.Segments[2].Trim('/');
}
```

## Suggested Test Case

Simulate a Key Vault challenge response with a DSTSv2 authorization URI and verify the tenant ID is correctly extracted:

1. Mock a `401` response with header:
```
WWW-Authenticate: Bearer authorization="https://uswest2-passive-dsts.dsts.core.windows.net/dstsv2/{expectedTenantGuid}", resource="https://foo.bar.core.windows.net"
```
2. Mock a `200` response for the subsequent authenticated request.
3. Capture the tenant ID passed to the credential's `getToken` call.
4. Assert the captured tenant ID equals the expected GUID, **not** the literal string `"dstsv2"`.

## Labels

`KeyVault`, `bug`, `client`