fix: include isTokenBinding in CCA cache key to prevent bearer/PoP collision

[Gladwin Johnson VR (gladjohn)]

Problem

GetApplicationKey did not include the isTokenBinding flag in the CCA cache key. When the same app made a bearer call followed by an mTLS PoP call (or vice versa), both resolved to the same cache key — so the second call reused the CCA built for the first.

This caused MSAL to throw at request time:

A string-returning client assertion callback cannot be used over mTLS. Use a certificate credential or a ClientSignedAssertion callback that can return a token-binding certificate.

The root cause is that bearer builds the CCA with WithClientAssertion(Func<string>) while PoP builds it with WithClientAssertion(Func<ClientSignedAssertion>) or WithCertificate() — these are fundamentally incompatible credential wirings that must not share a cache entry.

Fix

Append -tokenBinding to the cache key when isTokenBinding = true. This is a minimal, backwards-compatible change:

• Existing bearer callers pass false (default) → their keys are unchanged.
• PoP callers get a distinct key → build a separate CCA with the correct credential wiring.

Test

Added GetOrBuildCca_BearerThenTokenBinding_DoesNotReturnCachedBearerApp which:

1. Builds a bearer CCA (isTokenBinding: false) — succeeds and caches.
2. Requests a PoP CCA (isTokenBinding: true) — with the fix, this is a cache miss and attempts a fresh build. Since the test uses a secret credential (which can't do mTLS binding), it correctly throws IDW10115.
3. Before the fix, step 2 silently returned the bearer CCA (no throw, wrong behavior).

Results

• 949/949 Microsoft.Identity.Web.Test pass (net9.0, 4 pre-existing skips)
• No API surface changes — GetApplicationKey is private, parameter has a default value