Exclude wslc.exe and wslcsession.exe from custom LSP providers

[Blue (OneBlue)]

Summary of the Pull Request

This change updates the installer logic to exclude wslc.exe and wslcsession.exe from custom LSP providers, like we already do with WSL executables.

PR Checklist

• Closes: Link to issue wslc not work on my compute, most of its command report WSAEOPNOTSUPP #41758
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• 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

[Copilot]

Copilot review overview

🟡 Changes recommended

The supported container.exe alias remains exposed to custom LSP providers.

Review effort: Balanced
Findings: 1

Open (1)

• Register container.exe with LSP_SYSTEM alongside wslc.exe · New

What changed in this PR

Extends installer LSP exclusions to WSLC executables.

Changes:

• Registers wslc.exe and wslcsession.exe as system applications.
• Expands installer validation for these executables.

File	Description
src/​windows/​wslinstall/​DllMain.cpp	Extends LSP category registration.
test/​windows/​InstallerTests.cpp	Verifies registration during installation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟢 Approval recommended

The installer and test changes consistently cover all WSLC executable paths.

Review effort: Balanced
Findings: None

Resolved since last review (1)

• Register container.exe with LSP_SYSTEM alongside wslc.exe