Bump Microsoft.CommandPalette.Extensions NuGet when runtime IIDs match

[nickknissen]

Goal

We currently vendor the CmdPal SDK in `tools/cmdpal-sdk/` because the published `Microsoft.CommandPalette.Extensions` NuGet packages don't match the WinRT IIDs the CmdPal runtime expects, so loading the extension fails. When Microsoft ships a NuGet package whose IIDs match the shipping runtime, we can drop the workaround entirely.

How to know it's safe

• Watch the NuGet feed for `Microsoft.CommandPalette.Extensions` and `...Toolkit` updates
• Build a quick test branch that references the NuGet package directly (no vendored DLL) and confirm CmdPal loads the extension on the latest CmdPal release
• If it loads, delete `tools/cmdpal-sdk/` and the corresponding csproj reference

When this closes

• The vendored `tools/cmdpal-sdk/` directory is gone
• `HomeAssistantCommandPalette.csproj` references the NuGet package directly
• The "Re-extract vendored CmdPal SDK" maintenance issue can be closed at the same time

[nickknissen]

Done in #31. Both acceptance criteria are met:

• tools/cmdpal-sdk/ is deleted.
• HomeAssistantCommandPalette.csproj references the Microsoft.CommandPalette.Extensions NuGet package directly (currently 0.9.260303001).

The premise turned out to be slightly off: the IIDs in the NuGet package already matched the Command Palette runtime. What the vendored copy was actually providing was Microsoft.CommandPalette.Extensions.winmd inside the MSIX, which the host needs to build the cross-process IExtension proxy. Without it, activation fails with E_NOINTERFACE and the extension loads with no commands. The csproj now forces that winmd into the publish output via the IncludeCmdPalSdkWinmdInPublish target, since the SDK package marks it CopyToOutputDirectory but not CopyToPublishDirectory.

The companion maintenance issue #29 is closed as obsolete.