Too many JVM options resulting in no-reuse of daemons

Given the following artificially constructed `.mvn/jvm.config`, the daemons are NEVER reused.

```
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent=ALL-UNNAMED

```

Removing a single line in this config immediately results in correct daemon reuse.
We have discovered that it does not matter what JVM options are used, it's only related to the total length of options.

(Running on MacOS, Apple Silicon, JDK 22 Temurin, mvnd 1.0.2)

Reproduce the issue with the repeated options in .mvn/jvm.config on the reported JDK and verify whether removing one line restores daemon reuse. Trace the daemon JVM-option handling from that configuration and compare the option-length boundary; done means long JVM option lists no longer prevent reuse.

Written by the indexing model from the issue text.