Long-lived `BitmapImage`s with `ms-appx://` source get unloaded or corrupted

### Describe the bug

I have a WinUI/WinAppSDK app that remains open & running for days or weeks at a time and have observed a regression in `BitmapImage` as of 1.6.240829007 that affects `BitmapImage` instances loaded from a `ms-appx://` source (only tested with PNG).

These `BitmapImage`s are created once and used repeatedly in the app (via the backing `ImageSource` property of `Image` instances). Everything starts off fine but after some time the images in the UI that are loaded from the `ms-appx://`-backed `BitmapImage` end up blanking out (*as if* the `BitmapImage`s were null, even though the `BitmapImage` is not null, the `Image` in question is not null, and the `Image.Source` corrects to the correct `BitmapImage` instance).

Re-setting the `Source` property of the `Image` to the same `BitmapImage` value does not help, neither does calling `PropertyChanged` for the `Image` property of the bound object.

In this app, the same UI field is populated either with a dynamically created `BitmapImage` or with one of several fallback `ms-appx://`-backed `readonly static BitmapImage`s loaded once at app startup and never written to or modified thereafter. The images that were created from a dynamically created `BitmapImage` continue to display correctly but only images loaded from a `BitmapImage` backed by a (png) `ms-appx://` url end up being corrupted/broken (though they continue to appear to be loaded just fine when inspecting the state of the software in the debugger, instead of visually).

This behavior was observed after upgrading from WindowsAppSDK version 1.5.240627000; I don't believe the previous version exhibited this behavior even after the app was left running for weeks.

For context, the image is a property of a UI element that is bound to a list view's item template, so there is a huge list that has been virtualized and the "profile picture" is either loaded from a per-item value or falls back to a static generic placeholder. So the same code applies to thousands of entries in the list view but after days it is only those that point to the statically loaded `ms-appx://`-mapped BitmapImage that end up no longer appearing in the UI while those that were dynamically constructed and not backed by an `ms-appx://` url continue to work. There is no code that operates specifically on entries that don't have a custom per-entry image, the same code that touches one touches the other. The `readonly static BitmapImage` loaded from the `ms-appx://` is not even referenced anywhere in the code besides being mapped via a Xaml source converter in the same ternary expression as the one that uses the dynamically constructed BitmapImage instead.

### Steps to reproduce the bug

1. Add a PNG to the `Assets` folder
2. Add an `Image` to your XAML form, possibly as a member of a `ListView` with 1000s of entries so that some of them are virtualized with multiple of them sharing the same `BitmapImage` source.
3. At startup, create a `BitmapImage` with its uri set to `ms-appx://path/to/image.png`
4. Bind the `Image`'s `Source` property to the `BitmapImage` for many of the `ListView` images, some at the top of the list, some in the middle, and some at the end.
5. Leave the app running for an extended period of time, switch virtual desktops, minimize the app, run it in the background, leave it unfocused for a day+ at a time, etc.

### Expected behavior

Regardless of whether the `BitmapImage` was sourced from an `ms-appx://` URL or from a dynamically created `BitmapImage`, it should remain resident in the UI if it hasn't been unset, modified, or disposed.

### Screenshots

_No response_

### NuGet package version

None

### Windows version

_No response_

### Additional context

_No response_

Start with the reported reproduction using an Image in a XAML form or virtualized ListView, a PNG in the Assets folder, and a startup-created BitmapImage using an ms-appx:// URI. Compare behavior across Windows App SDK 1.5.240627000 and 1.6.240829007 while the app remains backgrounded for an extended period; done means the shared image remains visible and usable.

Written by the indexing model from the issue text.