Fix the WebClient plugins' NPE when writeTo runs before the exit spanis created

[eye-gu]

Fix

• Add a unit test to verify that the fix works.
• Explain briefly why the bug exists and how to fix it.

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes WebClient plugin throws NPE skywalking#13589.
• Update the CHANGES log.

[wu-sheng]

The deferred injection in afterMethod breaks requests when the exchange Mono is re-subscribed, e.g. a retry inside an ExchangeFilterFunction:

.filter((req, next) -> next.exchange(req)
    .flatMap(r -> r.statusCode().is5xxServerError()
        ? r.releaseBody().then(Mono.<ClientResponse>error(new IllegalStateException("5xx")))
        : Mono.just(r))
    .retry(1))

With JdkClientHttpConnector (and Jetty / HttpComponents, which also call writeTo eagerly), writeTo runs only once at assembly, so the retry re-subscribes the same Mono.defer wrapper against the same ClientHttpRequest. The first attempt already committed that request, so getHeaders() returns read-only headers and set throws UnsupportedOperationException. The supplier runs inside the application's reactive chain, not inside InstMethodsInter, so the agent doesn't swallow the exception. It becomes the request's error.

I reproduced it against Spring 6.2.19 with the JDK connector, a server that returns 503 and then 200, and the deferred injection emulated as in this PR:

Case	Result
no agent	retry succeeds
deferred injection as in this PR	request fails, cause UnsupportedOperationException
deferred injection wrapped in try/catch	retry succeeds, a single sw8 value is sent

Before this PR the NPE was caught and only logged, so as written this turns a logging problem into a request failure. Could you guard the deferred injection in both the 5.x and 6.x interceptors? For example:

if (contextCarrier != null) {
    try {
        inject(clientHttpRequest, contextCarrier);
    } catch (Throwable t) {
        // headers are read-only once the request is committed (e.g. re-subscribed by a retry)
    }
}

[eye-gu]

@wu-sheng Thanks! Fixed with the suggested try/catch in both interceptors.