Invalid request number, must be greater than 0

[lampajr]

Describe the bug
Occasionally when emitting new events for the dataset-event channel, we hit the following error:

2025-06-25 10:59:45,580 645a1466d4ef /usr/lib/jvm/java-17-openjdk-17.0.15.0.6-2.el9.x86_64/bin/java[7] ERROR [io.sma.rea.mes.amqp] (vert.x-eventloop-thread-1) SRMSG16225: Failure reported for channel `dataset-event-out`, closing client: java.lang.IllegalArgumentException: Invalid request number, must be greater than 0
	at io.smallrye.mutiny.helpers.Subscriptions.getInvalidRequestException(Subscriptions.java:24)
	at io.smallrye.mutiny.operators.multi.MultiOperatorProcessor.request(MultiOperatorProcessor.java:117)
	at io.smallrye.mutiny.operators.multi.MultiOnRequestInvoke$MultiOnRequestInvokeOperator.request(MultiOnRequestInvoke.java:34)
	at io.smallrye.reactive.messaging.amqp.AmqpCreditBasedSender.setCreditsAndRequest(AmqpCreditBasedSender.java:163)
	at io.smallrye.reactive.messaging.amqp.AmqpCreditBasedSender.lambda$onNoMoreCredit$7(AmqpCreditBasedSender.java:218)
	at io.vertx.mutiny.core.Context.lambda$runOnContext$1(Context.java:136)
	at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:270)
	at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:252)
	at io.vertx.core.impl.ContextInternal.lambda$runOnContext$0(ContextInternal.java:50)
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840)

The main problem is that this forcefully closes the connection with the AMQP broker with that specific channel causing Horreum to not work as expected.

To Reproduce

Couldn't find a deterministic reproducer so far but from the logs we hit this from time to time

[lampajr]

This seemed to be a wider problem that has been addressed here smallrye/smallrye-reactive-messaging#3196.

As shared in comment smallrye/smallrye-reactive-messaging#3196 (comment) we should upgrade smallrye-reactive-messaging to 4.31.0 as soon as released (actually it would be about upgrading to the latest version of Quarkus that uses this new release).