[WinUI3] No way to handle access keys in island app

### Describe the bug

We are currently implementing a xaml island app similar to the sample [here](https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Islands/SimpleIslandApp/cpp-win32-unpackaged), which has a WinUI navigation view embedded in an MFC window.

The issue is that the WinUI content needs to have keyboard focus to handle the alt keypress and display the access keys and if we shift focus when detecting the keypress in `PreTranslateMessage`, it is too late and the `WM_SYSKEYDOWN` event is missed by WinUI.

It seems at the moment that WinUI needs to detect both `WM_SYSKEYDOWN` and `WM_SYSKEYUP` for this to work but it only actually responds on the key up event. Would it be possible to make it only require the key up event as a workaround for this use case? Or even better, if there was a way for us to programmatically trigger the access keys we wouldn't need any workarounds for this.

### Steps to reproduce the bug

Run the attached app. After clicking either Win32 button, it is no longer possible to display the access keys for the navigation view by pressing the alt key

[cpp-win32-unpackaged.zip](https://github.com/user-attachments/files/23549004/cpp-win32-unpackaged.zip)

### Expected behavior

Access keys may be used regardless of what element has focus.

### Screenshots

_No response_

### NuGet package version

None

### Packaging type

Unpackaged

### Windows version

Windows 11 version 24H2 (26100, June 2025 Update)

### IDE

Visual Studio 2022

### Additional context

_No response_

Start by running the attached cpp-win32-unpackaged.zip sample and reading the PreTranslateMessage path in the MFC host. Trace how focus changes affect WM_SYSKEYDOWN and WM_SYSKEYUP delivery to the embedded WinUI navigation view. Done means access keys can be displayed after either Win32 button is clicked, as described in the expected behavior.

Written by the indexing model from the issue text.