fix(decoder): copy collection in ContainsDecoder to prevent IndexOutOfBoundsException during watchdog renewal (#7402) - #7404

Problem

In ContainsDecoder, passing a List previously skipped copying and stored the instance directly:

public ContainsDecoder(Collection<T> args) {
    if (args instanceof List) {
        this.args = (List<T>) args;      // aliased caller's list
    } else {
        this.args = new ArrayList<>(args);
    }
}

During lock watchdog renewal in LockTask.renew(), the caller dispatches the command and immediately registers a completion callback that mutates the same keys list:

new RedisCommand<>("EVAL", new ContainsDecoder<>(keys)),
...
return f.thenCompose(existingNames -> {
    keys.removeAll(existingNames);
    ...
});

When a response arrives late or is decoded across a retry/channel switch after the callback has already mutated the collection, decode() iterates over parts matching the original number of keys, but accesses args.get(index) from the shrunken list, throwing:

java.lang.IndexOutOfBoundsException: Index 1 out of bounds for length 1
    at java.base/java.util.ArrayList.get(ArrayList.java:428)
    at org.redisson.client.protocol.decoder.ContainsDecoder.decode(ContainsDecoder.java:50)

Because this exception aborts decoding, the renewal future never completes, stalling the watchdog loop and allowing held locks to expire under lockWatchdogTimeout.

Solution

Always defensive-copy the collection into a new ArrayList in ContainsDecoder constructor:

public ContainsDecoder(Collection<T> args) {
    this.args = new ArrayList<>(args);
}

Added JUnit 5 regression test suite ContainsDecoderTest verifying:

1. Mutating the caller's key list after decoder creation does not affect decoding or throw IndexOutOfBoundsException.
2. Standard decode operations return the expected matched keys.

Fixes #7402.