Test + doc: x-ms-tokenboundauth header for AKV mTLS PoP via ExtraHeaderParameters

[Gladwin Johnson VR (gladjohn)]

Summary

Azure Key Vault requires x-ms-tokenboundauth: true on mTLS PoP requests to trigger TLS renegotiation for client certificate binding. Without it, AKV returns 401: Client certificate required for using MTLS_POP token.

This PR validates and documents that IdWeb's existing ExtraHeaderParameters config surface handles this correctly — no production code changes needed.

Changes

• 16 unit tests covering:
  • Happy path (commercial + sovereign clouds)
  • MSI system-assigned and user-assigned full config shape
  • FIC full config shape
  • Duplicate prevention (case-insensitive)
  • Reserved header filtering
  • CustomizeHttpRequestMessage dynamic approach
  • Non-AKV resources correctly omit the header
• Updated daemon-app-msi-mtls sample with ExtraHeaderParameters in appsettings.json
• Documented the AKV requirement in Program.cs header comment

Developer configuration

{
  "AzureKeyVault": {
    "BaseUrl": "https://myvault.vault.azure.net/",
    "RequestAppToken": true,
    "ProtocolScheme": "MTLS_POP",
    "Scopes": ["https://vault.azure.net/.default"],
    "AcquireTokenOptions": {
      "ManagedIdentity": { "UserAssignedClientId": "<your-client-id>" }
    },
    "ExtraHeaderParameters": { "x-ms-tokenboundauth": "true" }
  }
}

Why not a DelegatingHandler?

Per reviewer feedback: hardcoding vault host strings is brittle. ExtraHeaderParameters is the IdWeb-native extensibility point — it's declarative, JSON-configurable, and lets each developer control which services get the header.

[Bogdan Gavril (bgavrilMS)]

No hardcoding of resource strings. Brittle solution. Ppl should use extra header API