I didn't remember that localization is so nice we do it twice

See #5533 
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5534)

The loc pipeline uses windows-2019 agents that are being deprecated.
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5538)

###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5532)

## Change
Call `CoAllowSetForegroundWindow` from the PS module to prevent/reduce
instances of the UAC prompt being launched but not foreground.

## Change
Use `UseProdCLSIDs` rather than `WingetDisableTestHooks` to drive the
dev/not-dev decision in DSC v3 resources. This only matters to the
internal local builds; everywhere else they are the same value.

The last couple of builds have failed due to a missing SDK version
10.0.22621.0, presumably due to the agent images being updated to remove
this. The only project where we use this version is CommonCore,
everywhere else we use 26100 already. This PR updates CommonCore to use
the same SDK version as all the other projects.
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5570)

`Repair-WinGetPackageManager` is failing to install winget in some Win10
systems. The issue seems come from #5517 and be caused because in some
cases we fail to mark any one architecture as the right one to use for
dependencies. This PR is a partial revert of #5517 to add the previous
logic as a fallback.

May fix #5559 (but I haven't set up an environment to test it...)
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5568)

We are seeing a crash coming from cpprestsdk, which happened after
moving to use vcpkg dependencies and updating to v2.10.19. This reverts
to the version we knew to be good, but it may be that the actual issue
is not from cpprestsdk but from one of the patches from vcpkg.

We consume cpprestsdk from a local port overlay that we use to be able
to patch it with support for certificate pinning, so the main change is
to the script that creates the port overlay. The script makes a copy of
the port from the official registry; and this PR updates it so that it
can fetch a version from an older commit and not just the latest.
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5567)

…5564)

### What was fixed

[CompletionData.cpp](cci:7://file:///c:/Users/T2430514/Downloads/winget-cli/src/AppInstallerCLICore/CompletionData.cpp:0:0-0:0)
passed a potentially negative `char` to `std::isspace`, invoking
undefined behaviour on non-ASCII input (signed `char` platforms). This
occasionally caused crashes or incorrect cursor repositioning when
autocompleting commands containing UTF-8 characters.

### How it was fixed
The character is now explicitly cast to `unsigned char` before the
`std::isspace` check:

```cpp
!std::isspace(static_cast<unsigned char>(commandLine[cursor - 1]))
```

This aligns with standard C++ guidance and makes the completion logic
robust across all locales.
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5564)

Co-authored-by: Odio Marcelino <odiomarcelino@gmail.com>

#5567 didn't actually fix the crash we were seeing.

The actual cause of the crash seems to be that I missed adding some
compilation flags that we had added to the `.vcxproj` for cpprestsdk
when I moved the dependencies to vcpkg (which does not use the
`.vcxproj`). Specifically, I didn't set a flag to compile it without
async support, so the library used async but winget wasn't prepared for
that.

This PR adds the missing compilation flags for all ports, taken from the
project files before the migration to vcpkg. I added the flags to the
triplet files (conditionally) so that it applies the same regardless of
whether a port comes from the official registry or a local overlay.

I noticed that for `libyaml` and `jsoncpp` I missed the flags to prepare
for fuzzing, so I added a new triplet for those.

This PR also updates the pipeline to publish the compilation logs from
vcpkg for easier debugging in the future.
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5587)

Yet another attempt to fix that crash we are seeing 🙃
See #5587

In the past we had added `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` globally
to fix a similar crash using `Directory.Build.props`, but that does not
flow from MSBuild to vcpkg. This change adds it to all the ports we use.
###### Microsoft Reviewers: [Open in
CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/5592)

## Change
Catch errors coming from `FindProvisionedPackages` and ignore them. This
is most likely to happen when the caller is not elevated.

## Change
Starting with the time that the UndockedRegFreeWinRT change was
introduced and working backward through commits, I found the equivalent
one (only whitespace changes are present, probably due to
auto-formatting). This change uses the existing overlay infrastructure
to update the detours port to that commit.

## Change
The reason for this configuration and build step have been lost. If this
builds just fine, I think we are safe to remove it.

Discussion on further MCP work:
#5609

## Change
This change adds an MCP server that provides two tools:

- Find packages
- Searches for packages based on a single input value, returning
information about each one found.
- Install package
- Installs a package given a single input value, which is expected to be
an identifier, name or moniker (same rules as `winget` CLI)

The package response looks like:
```JSON
{
  "identifier":"Microsoft.VisualStudioCode",
  "name":"Microsoft Visual Studio Code",
  "catalog":"winget",
  "isInstalled":true,
  "installedVersion":"1.102.1",
  "installedLocation":"%LOCALAPPDATA%\\Programs\\Microsoft VS Code\\",  <- Is actually real path, not tokenized
  "isUpdateAvailable":false
}
```

Also includes:
- A group policy that determines whether the MCP server is allowed to
operate
- An `mcp` command that helps with manually configuring an MCP client
- A change to the default COM caller behavior that makes it only use the
file name
- Also changes to not use the package family name if it is the same as
the current process (so we can better differentiate our own callers)
- A `Version` property on the `PackageManager` COM object that returns
the version string as `1.2.3` or `1.2.3-preview`.
- Start preferentially using this in the PowerShell module to get the
version rather than running the CLI