[improve][client] PIP-478: allow a provider-only CLIENT_OAUTH2 policy so an IdP on system trust can be pinned

The OAuth2 plugin contributes a `TlsPurpose.CLIENT_OAUTH2` policy only when the flow carries its own IdP
TLS *material* (`trustCertsFilePath`, `tlsCertFile` or `tlsKeyFile`). A flow with none contributes no
policy at all, so `CLIENT_OAUTH2` resolves terminally to the system default and stays unpinned.

Since #26326 the IdP leg can be pinned on both provider axes — explicitly through the `jsseProvider` /
`jcaProvider` OAuth2 parameters, or inherited from the client's composed `CLIENT_DEFAULT` — but only when
there is a policy to carry the pins. The common FIPS case of an IdP with a publicly-trusted certificate
(no custom trust material) therefore cannot be pinned: the token fetch parses that certificate through
the JVM provider search order while the broker connection is inside the validated module.

`pip-478.md` already names this as a deliberate follow-up rather than an oversight ("A provider-only
policy for that case is a deliberate follow-up rather than part of this PIP"), because a policy that
carries providers but no material has to be built without implying cluster trust material or enabling
transport TLS.

Scope: contribute a provider-only `CLIENT_OAUTH2` policy when either provider axis resolves and no IdP
material is configured; keep the existing precedence (explicit OAuth2 parameter, then framework-bound
`CLIENT_DEFAULT` inheritance, then unset) and keep the standalone path free of the inheritance step. Add
standalone, client-bound, admin-bound and no-provider regression tests.

Deferred out of #26326 as agreed in review; see [the re-review summary](https://github.com/apache/pulsar/pull/26326#issuecomment-5334709320) for where it sits relative to that PR.