[improve][fn] PIP-478: propagate the TLS provider pins to function-instance clients

Since #26326 the functions worker's own `PulsarClient` and `PulsarAdmin` carry all three
`brokerClient*` provider pins (`brokerClientSslProvider`, `brokerClientJsseProvider`,
`brokerClientJcaProvider`), and an embedded worker inherits them from the broker configuration.

The clients created *inside* a function instance do not. `FunctionRuntimeManager` reduces `WorkerConfig`
to `AuthenticationConfig`, which has no engine, JSSE or JCA provider fields, so the thread-runtime
function client — and the admin optionally exposed to functions — cannot inherit the worker's provider
selection. A FIPS deployment that pins BCJSSE and BCFIPS for the worker gets function instances running
on the JVM provider search order.

This is outside PIP-478's stated scope, which promises the pins on the worker's *own* client and admin,
so it does not block #26326. Closing it means extending the function-instance authentication
configuration and the runtime handoff to carry the applicable pins, deciding whether a local-run override
or the worker default wins, and testing both the runtime client and the exposed admin.

Found while verifying #26326.

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.