fix(mp-rest-client): do not auto-propagate InboundHeadersProvider headers

[arimu1]

Summary

Fixes nondeterministic leakage of application InboundHeadersProvider headers into outbound MicroProfile Rest Client requests (even when no ClientHeadersFactory is registered).

Root cause

• DefaultInboundHeaderProvider and application InboundHeadersProvider instances were stored in a plain HashSet (unordered).
• MethodModel.resolveCustomHeaders() accumulates every provider's inboundHeaders() into one map.
• When DefaultInboundHeaderProvider is visited, its ClientHeadersFactory.update() copied that entire accumulated map into outbound headers.

So if an application provider was iterated before the default provider, inbound-only headers (e.g. Authorization, Cookie) were sent to the remote target. Order depended on HashSet iteration / hash bucket layout, so different client instances in the same JVM could differ.

Fix

1. Use LinkedHashSet for inbound header providers in RestClientBuilderImpl and RestClientContext.Builder so DefaultInboundHeaderProvider (registered first) stays first.
2. Harden DefaultInboundHeaderProvider.update() to only apply RestClientBuilder.header(...) values, never headers from other InboundHeadersProviders. Those remain available only to an explicit @RegisterClientHeaders / ClientHeadersFactory.

Testing

mvn -pl tests/integration/microprofile/rest-client -am test \
  -Dtest=InboundHeadersProvider* \
  -Dsurefire.failIfNoSpecifiedTests=false

• InboundHeadersProviderLeakTest 3/3 (100× no-leak stress, builder header still applied, explicit factory still sees inbound)
• InboundHeadersProviderTest 2/2
• Temurin/JBR 17

Related

Fixes #6101

Co-reported / analysis by @Verdent; @OndroMih noted the LinkedHashSet ordering requirement.

Signed-off-by: arimu1 19286898+arimu1@users.noreply.github.com