Fix fetch wait duration validation for NATS backend

RqueueMessagePoller passes Duration.ZERO when calling pop(), which works
for Redis (used as 'no timeout'). However, JetStreamMessageBroker forwards
this to JetStream's fetch() API, which requires a positive duration and
rejects ZERO.

Fix: Treat ZERO duration the same as null - use config.getDefaultFetchWait()
instead. This maintains compatibility with the Redis poller interface while
ensuring JetStream gets a valid fetch duration.

Solves: "Fetch wait duration must be supplied and greater than 0" errors
during polling.

Assisted-By: Claude Code

Author: sonus21

rqueue-nats/src/main/java/com/github/sonus21/rqueue/nats/js/JetStreamMessageBroker.java

@@ -276,7 +276,9 @@ private static String resolveConsumerName(String queueName, String consumerName)
 
   private List<RqueueMessage> popInternal(
       String stream, String subject, String consumerName, int batch, Duration wait) {
-    Duration fetchWait = wait != null ? wait : config.getDefaultFetchWait();
+    // Use default fetch wait if none provided OR if zero duration is passed (Redis compatibility).
+    // JetStream requires a positive duration for fetch().
+    Duration fetchWait = (wait != null && !wait.isZero()) ? wait : config.getDefaultFetchWait();
     String key = stream + "/" + consumerName;
     JetStreamSubscription sub = subscriptionCache.computeIfAbsent(key, k -> {
       // computeIfAbsent runs at most once per (stream, consumer) per JVM, so both the stream