This is correcting the first fix attempt: #31026

Now really fixes #31024

I ran into this issue during test execution in Maven modules that are testing stuff via quarkus-rest-client-reactive, but don't have quarkus-resteasy-reactive on their classpath.
They do however have a "common" module on their CP that contains a `ContainerResponseFilter` with a single constructor that takes an OTel `Span` (could be any other injectable type though).
What happened is that the rest client setup tried to instantiate the server-side filter (which it shouldn't at all) via the default no-arg constructor - which doesn't exist:
```
java.lang.RuntimeException: java.lang.NoSuchMethodException: de.someproj.register.common.trace.TraceHeaderResponseFilter.<init>()
at org.jboss.resteasy.reactive.common.jaxrs.ConfigurationImpl.register(ConfigurationImpl.java:211)
at org.jboss.resteasy.reactive.client.impl.ClientBuilderImpl.register(ClientBuilderImpl.java:344)
at io.quarkus.rest.client.reactive.runtime.RestClientBuilderImpl.register(RestClientBuilderImpl.java:207)
at io.quarkus.rest.client.reactive.runtime.RestClientBuilderImpl.build(RestClientBuilderImpl.java:316)
```

It's not that easy to reproduce, because `quarkus-resteasy-reactive` must not be present - otherwise that extension will register the filter as a CDI bean and the lookup in the client setup will take a different path and won't try to instantiate the filter on its own.
I tried adding a `QuarkusUnitTest` but `quarkus-rest-client-reactive-deployment` has a test dependency on `quarkus-resteasy-reactive-jackson-deployment` and so the test archive will contain `quarkus-resteasy-reactive` and I don't see an easy way to get rid of it.

Anyhow, I tested the fix via: https://github.com/famod/quarkus-quickstarts/commit/ff318bbfb0ba6de263bbb0c199cac91542c1fd88 (please ignore the beans.xml)

• clone https://github.com/famod/quarkus-quickstarts/tree/issue-31024-client-server-filter
• cd rest-client-reactive-quickstart
• mvn clean test