When translating clipboard to numpad events, use the *input* CP (#19511)

I looked as far back as I was able to find, and we've used the OutputCP
since at least Windows NT 3.51.

I think it has _never_ been correct.

At issue today is the GB18030-2022 test string, which contains the
following problematic characters:

* `ˊ` `U+02CA` Modifier Letter Acute Accent
* `ˋ` `U+02CB` Modifier Letter Grave Accent
* `˙` `U+02D9` Dot Above
* `–` `U+2013` En Dash

They cannot be pasted into PowerShell 5.1 (PSReadline).

It turns out that when we try to synthesize an input event (Alt down,
numpad press, Alt up **with wchar**) we are using their output codepage
65001. These characters, of course, do not have a single byte encoding
in that codepage... and so we do not generate the numpad portion of the
synthesized event, only the alt down and up parts!

This is totally fine. **However**, there is also a .NET Framework bug
(which was only fixed after they released .NET Core, and rebranded, and
the community stepped in, ...) finally fixed in .NET 9 which used to
result in some Alt KeyUp events being dropped from the queue entirely.

dotnet/runtime#102425

Using the input codepage ensures the right events get synthesized. It
works around the .NET bug.

Technically, padding in those numpad input events is _also more
correct_.

It also scares me, because it has been this way since NT 3.51 or
earlier.

Author: DHowett

src/interactivity/win32/Clipboard.cpp

@@ -310,7 +310,7 @@ InputEventQueue Clipboard::TextToKeyEvents(_In_reads_(cchData) const wchar_t* co
             currentChar = UNICODE_CARRIAGERETURN;
         }
 
-        const auto codepage = ServiceLocator::LocateGlobals().getConsoleInformation().OutputCP;
+        const auto codepage = ServiceLocator::LocateGlobals().getConsoleInformation().CP;
         CharToKeyEvents(currentChar, codepage, keyEvents);
     }