FreeConsole API handle UAF/recycling issue

### Windows build number

10.0.10240.0

### Other Software

N/A

### Steps to reproduce

Windows 10 and 11 have an issue where the FreeConsole function closes the StandardInput, StandardOutput, StandardError and ConsoleHandle fields in the PEB but doesn't zero these values.

Windows recycles handle identifiers and since these values are not zeroed when they're closed, they start referencing an entirely different handle.

### Expected Behavior

The FreeConsole function zero the StandardInput, StandardOutput, StandardError and ConsoleHandle fields in the PEB after closing the handle.

### Actual Behavior

The FreeConsole function closes the handles but doesn't zero the StandardInput, StandardOutput, StandardError and ConsoleHandle fields in the PEB causing a use-after-free scenario.

### Sample

This sample project reproduces two separate issues:
[Project1.zip](https://github.com/user-attachments/files/20200428/Project1.zip)

You should hit this breakpoint when running the sample:
[Screenshot](https://github.com/user-attachments/assets/0f9a161e-b7ae-42f5-9af9-db1c135c77e5)

Otherwise if you hit this breakpoint from kernelbase/msvcrt then run the sample a few more times. kernelbase/msvcrt is calling GetStdHandle and unexpectedly referencing a process handle - from the sample - due to FreeConsole not zeroing the StandardInput, StandardOutput, StandardError and ConsoleHandle fields in the PEB:


It's the same issue but less obvious.

Start by running the linked Project1.zip sample on the reported Windows builds and inspect the FreeConsole and GetStdHandle behavior described in the reproduction steps. Determine whether this belongs in the Windows Terminal codebase or requires an upstream Windows fix; done would require a confirmed fix with the sample no longer observing recycled handles.

Written by the indexing model from the issue text.