[🐛 Bug]: Second driver's discovery logging still misses a debug switch flipped mid-run

### Feature and motivation

Follow-up from #17832 (part of the umbrella tracker, see linked issue).

`RemoteWebDriver`'s static initializer (JLS 12.4.2) is guaranteed to run once, before any subclass constructor body — including argument expressions passed to a subclass's own `super(...)` call, which is where `ChromeDriver`/`FirefoxDriver` perform `DriverFinder`/Selenium Manager discovery logging. #17832 uses that static initializer to make the *first* driver constructed in a JVM correctly pick up the debug switch for its own discovery logging.

That only covers the first driver. For a second (or later) driver, if the debug switch is flipped between the first and second construction, that second driver's own discovery logging still runs — via its `super(...)` argument evaluation — before `Debug.configureLogger()` is reached inside the instance constructor body. Its discovery logging is still missed.

This is not a regression: the gap has always existed on trunk. #17832 narrows it (first-driver case now works) but explicitly does not close it, and flags it as a maintainer call in its "Additional Considerations" section.

### Options (not evaluated in depth yet — for whoever picks this up)

1. Move (or duplicate) the `Debug.configureLogger()` call earlier, into `DriverFinder`/Selenium Manager's own discovery-logging call sites directly, so it no longer depends on being reached via any particular constructor's control flow.
2. Give `ChromeDriver`/`FirefoxDriver` a static initializer of their own (JLS 12.4.2 runs a subclass's static initializer before any instance of it is constructed, but after the superclass's static initializer already ran) that calls `Debug.configureLogger()` — need to verify this actually resolves the *second*-driver case and not just duplicate the same first-instance limitation at a different class.
3. Accept the gap as a known limitation of static-initializer-timing and document it rather than fix it, if no clean fix exists that doesn't complicate driver subclass initialization further.

### Related

#12892, #17832 (see its "Additional Considerations" and Implementation Notes items 1–2 for the original writeup of this gap).

Start with #17832, especially its Additional Considerations and Implementation Notes, then trace RemoteWebDriver initialization through ChromeDriver/FirefoxDriver, DriverFinder, Selenium Manager, and Debug.configureLogger(). Evaluate the listed approaches against a second driver whose debug switch changes mid-run. Done means the behavior is either corrected and verified for that case or documented as an accepted limitation.

Written by the indexing model from the issue text.