fix: prefer chromedriverPorts pool over single chromedriverPort when both are set

[AsijitM]

Problem

setupNewChromedriver resolves the chromedriver port like this:

if (opts.chromedriverPort) {
  // use the single port
} else {
  opts.chromedriverPort = await getChromedriverPort(opts.chromedriverPorts);
}

If a caller provides both the single chromedriverPort and the chromedriverPorts
pool/range, the single port wins and the configured pool is silently ignored. There is then
no way to guarantee that a session picks a free port from the pool — which matters when
several parallel sessions run against the same host and rely on the pool to avoid collisions.

Fix

When both are provided, prefer a free port from the chromedriverPorts pool and log that the
single chromedriverPort is being ignored. Behavior is unchanged when only one of the two is set:

• only chromedriverPort → use it (as before)
• only chromedriverPorts → pick from the pool (as before)
• neither → pick any free port (as before)

Notes

• Small, self-contained change in setupNewChromedriver; no capability/schema changes.
• Happy to add a unit test for the precedence if maintainers prefer.

[mykola-mokhnach]

1. This is a breaking change
2. It is ok to prefer the concrete value of chromedriverPort if explicitly provided as it narrows down the scope more than chromedriverPorts. Not sure we want to accept this change