CmdPal: Separate in-flight icon loads from cached results

[Jiří Polášek (jiripolasek)]

Summary of the Pull Request

This PR is stacked on #49737 and separates in-flight icon loading from completed-result caching. The XAML request path no longer takes a provider-wide lock, while concurrent requests for the same icon still share a single task and completion cleanup can retire only that exact task generation.

The loader now reports whether queue admission succeeded, preventing requests rejected during shutdown from remaining pending indefinitely.

Overall, it seems that we got rid of a lock and actually reduced turnaround on UI thread. The separate in-flight tracking takes its tall, but overall throughput increased (tl;dr - it's faster).

• Deduplicate outstanding icon loads in a dedicated in-flight dictionary.
• Cache successful tasks before atomically retiring their in-flight entries.
• Keep failed and rejected loads out of the adaptive cache so they can be retried.
• Replace EnqueueLoad with TryEnqueueLoad and fault rejected requests.
• Add tests for concurrent loading, publication ordering, failures, rejection, and retries.

PR Checklist

• Closes: #xxx

• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

[Mike Griese (zadjii-msft)]

This might low key fix #47620. I'm trying to stand up a feature regression test in run to actually confirm that...

[Mike Griese (zadjii-msft)]

This makes sense to me, and looks like it's way more async, which is what we want.

I'm just weirded out about these shims in the cmdpal.ui.unitests, but whatever that's not worth blocking on.

[Mike Griese (zadjii-msft)]

These are... fake view models? but in the Microsoft.CmdPal.UI.ViewModels namespace?

[Jiří Polášek (jiripolasek)]

Oh squirrel, I'm pretty sure I hid them inside the test class (bandit), puzzling.

As for why: it builds much faster. The exe is self-contained, so the test project has to be too. I gave up on solving that problem in this PR, leaving us with a great conversation starter :)