CmdPal: Icons (8/n) - Add icon protocols and defer app icon extraction

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

Summary of the Pull Request

Part 8 of 12 in the CmdPal icon-loading series. Depends on #50187. Next: #50189.

This PR introduces protocol processors and makes Installed Apps submit requests instead of eagerly extracting icon streams.

• Centralizes declared-prefix matching and overlap validation in an AOT-friendly registry.
• Adds normal/jumbo app requests through existing IconInfo/IconData strings, preserving opaque icon candidates.
• Moves extraction into the bounded, demand-aware loader with a shared app placeholder.

Motivation: the host can schedule and share work that previously happened before the icon pipeline, without requiring a new SDK icon object.

Examples

Using Microsoft.CommandPalette.Extensions.Toolkit:

var icon = new IconInfo(AppIconProtocol.Create(@"C:\Apps\App.exe"));
var hero = new IconInfo(AppIconProtocol.CreateJumbo(@"C:\Apps\App.exe"));
var withFallback = new IconInfo(
    AppIconProtocol.Create(@"C:\Apps\App.exe", @"C:\Icons\App.ico"));

The first two requests serialize as:

|AppIcon|v1;15:C:\Apps\App.exe
|JumboAppIcon|v1;15:C:\Apps\App.exe

These strings can also be passed directly to IconInfo; the helpers avoid hand-counting payload lengths.

Evidence

Historical adjacent-stage comparison (2026-08-18); shared method and limitations: the diagnostics foundation PR #50181.

• A cold-ish process CPU: 156328.125 → 139140.625 ms (17.188 CPU-seconds less, −11.0%); all three pairs decreased.
• A cold-ish applied average: 4.250 → 6.014 ms (+1.764 ms); p95 bound ≤8 → ≤33 ms.
• C cold-ish applied average: 4.871 → 8.402 ms (+3.531 ms); p95 bound ≤33 → ≤100 ms. Both A and C averages worsened in all three pairs.
• C cold-ish applied new-load average: 48.894 → 90.405 ms (+41.511 ms); all three pairs worsened. This shows why the cold-miss cost matters more than the small blended average suggests.
• C warm applied average: 0.262 → 0.237 ms (−0.025 ms), inconsistent across pairs; this is not evidence of a meaningful warm speedup.
• Protocol tests cover malformed payloads, fallback candidates, and Unicode, including emoji.

Cold extraction moves onto the measured request's critical path instead of being prepaid by extension preloading. That explains the direction of the tradeoff—less process work, later cold icons—but does not prove the whole observed penalty is necessary or acceptable.

Technical notes

• This is a statically registered processor set, not a runtime extension plug-in loader. Extensions submit recognized strings; no reflection-based discovery is required for Native AOT.
• Prefix matching is ordinal and case-sensitive. The registry owns matching and rejects duplicate/overlapping declarations, so processor-specific matchers cannot disagree with declared prefixes.
• The payload is versioned and length-prefixed in UTF-16 code units, not bytes or grapheme clusters. App candidates can be paths, indexed references, or other icon strings; they must not all be interpreted or normalized as filesystem paths.
• A malformed claimed protocol must not fall through into unrelated glyph/path parsing.

Implementation: src/modules/cmdpal/Microsoft.CmdPal.UI/Helpers/Icons/IconProtocolRegistry.cs.

PR Checklist

• Closes: CmdPal: Icon loading (7/n) - Add an icon protocol registry and defer app icons #49940

• 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)]

gut check:

• this is a cool idea
• I spot a bunch of em-dashes in the comments, and the PR body is pretty unintelligible in the "Evidence" section. That could use some cleanup
• do we need to encode the path length in the protocol? like, it's a string? do we need to say how long the rest of the string is?

but otherwise this is a pretty clever solution

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

gut check:

• this is a cool idea

but otherwise this is a pretty clever solution

• I spot a bunch of em-dashes in the comments, and the PR body is pretty unintelligible in the "Evidence" section. That could use some cleanup

I have to re-order this entire stack to put everything into some sensible order and keep trace measurements somehow consistent between PRs, and I used toaster to rewrite and move the code around.

• do we need to encode the path length in the protocol? like, it's a string? do we need to say how long the rest of the string is?

Given the edge cases, it's the leaser evil. I've run into issues with URLs and encoding, the other reason was packing multiple protocols into one string (fallback icons, different icons per theme, etc...).