`CCoreServices::TryLoadXamlResourceHelper` inadvertently frees the loaded XAML before returning it

[fincs]

Describe the bug

https://github.com/microsoft/microsoft-ui-xaml/blob/main/src/dxaml/xcp/core/dll/xcpcore.cpp#L3069-L3076 is intended to detach the ownership of the IPALMemory in order to return it to the caller. However, https://github.com/microsoft/microsoft-ui-xaml/blob/main/src/dxaml/xcp/core/dll/xcpcore.cpp#L3046-L3048 means it is still owned by the IPALResource, and when spResource goes out of scope the memory is destroyed (m_embeddedDataBuffer inside CMRTResource's destructor gets CoTaskMemFree'd).

Why is this important?

This memory management bug causes the loaded XAML data to be corrupted as it is overwritten by heap management structures, resulting in unpredictable XAML parsing errors later on. The overall effect is that it is impossible to load XAML data from memory.

Steps to reproduce the bug

• Implement Microsoft.Windows.ApplicationModel.Resources.IResourceManager, and wire it up using the ResourceManagerRequested event
• Implement IResourceMap::TryGetValue, returning a ResourceCandidate made out of embedded XAML data in memory when it asks for resources such as Files/app.xaml
• Observe strange XAML parsing behavior and subsequent program failure

Actual behavior

No response

Expected behavior

No response

Screenshots

No response

NuGet package version

1.8.260317003

Windows version

Windows 11 (25H2): Build 26200

Additional context

I am experimenting with WinUI 3 in order to build a minimal unpackaged app that loads all of its resources from memory (among other things). As a sidenote, it seems IResourceManager's methods are expected to return WinRT objects belonging to sealed classes that have no public constructors; they should probably be fixed to return instead interface types that can be actually implemented (currently I am working around the issue).