Guard header copy against committed response in NettyRoutingFilter

[adityaanikam]

Fixes gh-4270

Problem

NettyRoutingFilter copies filtered response headers back onto the
client response near the end of filter():

response.getHeaders().remove(HttpHeaders.TRANSFER_ENCODING);
...
response.getHeaders().addAll(filteredResponseHeaders);

If the response has already been committed elsewhere in the filter
chain before routing completes, AbstractServerHttpResponse#getHeaders()
returns a cached ReadOnlyHttpHeaders wrapper instead of the mutable
headers map. Calling remove(...) or addAll(...) on that wrapper
throws UnsupportedOperationException, which surfaces as an error
signal on the filter chain instead of the response completing
normally.

Fix

Guard the header-copy step with response.isCommitted(). Once a
response is committed, headers can no longer reach the client
regardless, so skipping the copy is safe and matches an existing
precedent already in the test codebase
(BaseWebClientTests#modifyResponseFilter, which uses the same
isCommitted() check before touching response headers).

Testing

• Added NettyRoutingFilterTests#routingAfterResponseAlreadyCommittedDoesNotThrow,
  which pre-commits a MockServerWebExchange and asserts
  nettyRoutingFilter.filter(...) completes normally instead of
  erroring.
• Full NettyRoutingFilterTests suite passes.
• Verified with a negative control: reverting only the fix (keeping
  the new test) reproduces the exact reported
  UnsupportedOperationException at
  ReadOnlyHttpHeaders.remove(ReadOnlyHttpHeaders.java:166), matching
  the original issue's stack trace. Restoring the fix passes cleanly.