Remove uncertainty about freopen

In my subsequent debugging and testing, I found that removal of the
freopen calls negatively impacted the console behavior. It is definitely
necessary (at least on my Windows 11 system) in order to correctly
connect the console to the launcher.

doc/WINDOWS.md

@@ -52,7 +52,7 @@ What we'd really like is for our Windows EXE to behave the same way as Unix-like
 
 Windows programs compiled in GUI mode do not attach to the calling process's console by default *even in wait mode*; it must be done explicitly using the [`AttachConsole`](https://learn.microsoft.com/en-us/windows/console/attachconsole) function. Fortunately, the Jaunch native launcher does this, so that the above tricks (wait mode and batch file wrappers) work as desired.
 
-Unfortunately, even with `AttachConsole`—and even if we go further and use `freopen` to reopen the stdin/stdout/stderr, which I'm not sure even causes any changes in behavior on current versions of Windows—the invoked launcher is still in a bad state when run directly from the shell (without wait mode and without wrapping in a batch file). Firstly, on Windows, consoles can have multiple processes attached to them and "there is no guarantee that input is received by the process for which it was intended" ([source](https://learn.microsoft.com/en-us/windows/console/creation-of-a-console)); when control returns immediately to the shell before the launched program terminates, and then keystrokes are typed, each character gets sent to either the launched process or the shell process in a haphazard way, effectively splitting the input between the processes, resulting in a big mess.
+Unfortunately, even with `AttachConsole`—and even if we go further and use `freopen` to reopen the stdin/stdout/stderr, the invoked launcher is still in a bad state when run directly from the shell (without wait mode and without wrapping in a batch file). Firstly, on Windows, consoles can have multiple processes attached to them and "there is no guarantee that input is received by the process for which it was intended" ([source](https://learn.microsoft.com/en-us/windows/console/creation-of-a-console)); when control returns immediately to the shell before the launched program terminates, and then keystrokes are typed, each character gets sent to either the launched process or the shell process in a haphazard way, effectively splitting the input between the processes, resulting in a big mess.
 
 #### Recommendations