TouchKeyboardNotifier - Does not work properly with Per Monitor V2 DPI Scaling

With Per Monitor V2 DPI Scaling, the showingHandler code in TouchKeyboardNotifier does not return the correct occludedRect when the window which raised the event is on a non-primary monitor and that monitor's DPI scaling is different to the primary monitor's. It seems that the returned value assumes that it is coming from the primary monitor when it may not be. This issue may be in the underlying InputPane class this sample uses as it seems like that might be returning the incorrect values based on my investigation.

Note that this was tested with Per Monitor V2 Scaling enabled in the app manifest of a WPF app using both .Net Framework 4.8 and .Net Core 3.1. The WPF window itself scales fine and doesn't use bitmap stretching, but the occludedRect value produced in the showingHandler from this sample returns values that are too small or too big when the window which raised the event is on a non-primary monitor and that monitor's DPI scaling is different to the primary monitor's. When the WPF window is on a primary monitor, it seems to work fine regardless of DPI scaling.

Here is the expected behaviour (When WPF window is on a primary monitor):

And here it is on a secondary monitor whose DPI scaling is different from the primary monitors. The occludedRect is far to tall, resulting in most of the window being cut off when the content within it is resized to fit within the top of the touch keyboard and the top of the screen:

This was using Windows 11 but the issue occurs in Windows 10 too.

Start with the TouchKeyboardNotifier sample's showingHandler and trace how the InputPane occludedRect is obtained and interpreted. Reproduce the report on primary and non-primary monitors with different Per Monitor V2 DPI settings, then compare the resulting rectangle with the expected touch-keyboard bounds; done means the values are correct on both Windows 10 and Windows 11 scenarios described.