Detach ImdsV2ManagedIdentitySource from AbstractManagedIdentity (refused-bequest cleanup)

[Robbie-Microsoft]

Background

PR #6070 routed the IMDSv2 mTLS-PoP token leg through MSAL's internal TokenClient. As a side effect, ImdsV2ManagedIdentitySource still inherits AbstractManagedIdentity but no longer uses its token template:

• It calls none of the inherited template methods.
• It is forced to stub the abstract CreateRequestAsync with a throw — a classic "refused bequest" code smell.
• ManagedIdentityClient selects the source through the shared AbstractManagedIdentity-typed path and then downcasts back to ImdsV2ManagedIdentitySource.

This was raised during review of #6070 (review thread). We agreed to address it as a scoped follow-up rather than carry the tech debt.

Proposed fix

• Introduce an internal interface IImdsV2MtlsBindingSource exposing AcquireMtlsBindingForDelegationAsync.
• Have ImdsV2ManagedIdentitySource implement the interface instead of inheriting AbstractManagedIdentity; delete the throwing CreateRequestAsync override.
• Split source selection in ManagedIdentityClient into a decision helper (SelectManagedIdentitySourceType) and instantiation, replacing the downcast with a clean interface-typed path.
• Remove the obsolete ValidateServerCertificate_NotSetForImdsV2 test (asserts a base-class validation-callback behavior IMDSv2 no longer has).

Constraints

• No public API changes (all affected types are internal).
• Behavior preserved exactly: all source-selection guards, the discovery cache, mTLS PoP routing, and the min-strength enforcement added in Enforce mTLS PoP minimum binding strength for Managed Identity (#6049 Phase 2) #6059.

References

• Delegate IMDSv2 mTLS-PoP token leg to internal TokenClient exchange (MSIv2 WithClaimsFromClient) #6070 (delegation work that introduced the smell)
• Review thread: Delegate IMDSv2 mTLS-PoP token leg to internal TokenClient exchange (MSIv2 WithClaimsFromClient) #6070 (comment)