Identity Assertion Grant flow only supports OIDC ID tokens, not SAML 2.0 assertions

IdentityAssertionGrantProvider (added in #1305) hardcodes the RFC 8693 subject token type to urn:ietf:params:oauth:token-type:id_token in IdentityAssertionGrant.RequestJwtAuthorizationGrantAsync (subject_token_type = TokenTypeIdToken), and the public IdentityAssertionGrantIdTokenCallback returns only an ID token string. So today the flow is OIDC-ID-token-only.

RFC 8693 and the Identity Assertion Authorization Grant draft also allow SAML 2.0 assertions as the subject token. The Python SDK (PR #1721) parameterizes subject_token_type to support this. We even already declare an unused TokenTypeSaml2 constant in IdentityAssertionGrant.cs, which implies support we don't actually have.

Suggested direction

Adding SAML 2.0 support would be additive and doesn't need to block #1305:

• Either introduce a parallel subject-assertion callback (e.g. a SubjectAssertionCallback returning the assertion plus its token type), or add a subject-token-type field on IdentityAssertionGrantProviderOptions and thread it through the RFC 8693 exchange.

Until then, we should either wire up TokenTypeSaml2 or drop the unused constant so the code doesn't imply unsupported functionality.

Related: #1305

Start by reading IdentityAssertionGrant.cs, especially IdentityAssertionGrantProvider, RequestJwtAuthorizationGrantAsync, IdentityAssertionGrantIdTokenCallback, and the unused TokenTypeSaml2 constant. Trace how IdentityAssertionGrantProviderOptions reaches the RFC 8693 exchange, then determine whether the callback or options approach fits; done means SAML 2.0 assertions are accepted while existing OIDC ID-token behavior remains supported, or the unused constant is removed if support is not added.