thread-per-core: provider-key TLS clients still use a process-wide pool

Raised by review on #891; split out as the known scope cut it was.

In thread-per-core mode the standard dispatch path uses a per-worker client (worker_client()), but a provider key with a tls override resolves through the process-wide PK_CLIENTS cache (crates/aisix-gateway/src/upstream_tls.rs, client_for_provider_key). Requests using such keys share one upstream pool across workers, so their upstream responses can land on a foreign thread and pay the cross-thread wakeup this mode exists to remove. Correctness is unaffected; custom-TLS keys just do not get the locality win.

Why it shipped this way: a per-worker x per-TLS-config client matrix multiplies connection pools (N workers x M configs), and custom-TLS provider keys are the rare path. If this gets picked up: a worker-local cache keyed by ProviderKeyTls for tpc-* threads with the shared cache kept for everything else, plus a bound or eviction so the matrix cannot grow unbounded.

Start in crates/aisix-gateway/src/upstream_tls.rs at client_for_provider_key and compare its process-wide PK_CLIENTS path with the per-worker worker_client() dispatch path. Implement the worker-local ProviderKeyTls cache only for tpc-* threads, retain the shared cache elsewhere, and ensure the cache is bounded or evicts entries so the worker-by-TLS configuration matrix cannot grow without limit.