Fix async Rest5 client withHeaders() not seeing ThreadLocal auth (#3300)

[014-code]

Summary

ClientConfiguration.withHeaders() configured with a Supplier<HttpHeaders> that reads a ThreadLocal (typical for Spring Security's SecurityContextHolder) silently fails on the new Rest5 async client.

Root cause

Rest5Clients.getRest5ClientBuilder(...) registered the headers supplier as an HttpRequestInterceptor on the HttpAsyncClientBuilder. In HC 5, request interceptors run on the I/O reactor thread, so the supplier executes off the calling thread and cannot see any ThreadLocal set by the caller.

The legacy RestClients (HC 4) used addInterceptorLast, which runs synchronously on the calling thread, so the bug does not manifest there.

Fix

Replace addRequestInterceptorFirst with addExecInterceptorFirst. The AsyncExecChain handler executes on the calling thread before the request is dispatched asynchronously, so the supplier now sees the caller's ThreadLocal.

While there, fix a pre-existing typo: " Content-Type" had a leading space so the override never matched the real Content-Type header.

Regression test

RestClientsTest.shouldConfigureClientAndSetAllRequiredHeaders now:

1. Reads a ThreadLocal inside the headers supplier and exposes the value as a thread header.
2. Sets the ThreadLocal on the calling thread before invoking client.ping().
3. Verifies that wireMock received the thread: local header.
4. Asserts the supplier thread name equals the calling thread name, locking in the root cause against future regressions that would move the supplier back onto the async I/O thread.

The test runs against all three client factories (ElasticsearchRestClient / ElasticsearchRest5Client / ReactiveElasticsearchClient (ELC based)). Only the Rest5 factory exercises the changed code; the others serve as a regression net.

#3300