windows output capture can log unboundedly when the console echo write fails

Follow-up from the review of #18399, which fixed the Posix instance of this bug (#18398).

`src/cpp/core/system/Win32OutputCapture.cpp` has the same unbounded-logging shape in `standardStreamCaptureThread`, in two places:

- A failed `WriteFile` to the saved `CONOUT$` handle calls `LOG_ERROR` on **every** failure, with no "skip further writes" flag at all (the echo block around lines 62-75). With a stderr log destination active, each logged error is written to the redirected stderr pipe, read back by the stderr capture thread, echoed to the console handle, fails again, and logs again -- the same self-sustaining full-CPU loop fixed for Posix in #18399.
- A `ReadFile` failure is logged inside `while (true)` with no break or backoff (lines 78-83), so a persistent read error would also log unboundedly.

Reachability is lower than on Posix, which is why this was split out rather than fixed in #18399: in Desktop mode there is no console, so `CreateFile("CONOUT$")` fails once at startup and the original-handle argument stays `nullptr` (the caller initializes it that way), disabling the echo path entirely. The exposure is a Windows session with a console attached and `log-stderr=1` -- the only caller passes `options().logStderr()` as `forwardOutputToOriginalDescriptors` -- where the console handle later becomes unwritable.

The fix would mirror #18399: on a persistent echo-write failure, stop echoing and log the error once, and bound the `ReadFile` error logging as well.