Add DSC v3 profile resource to deploy key and shortcut remappings

[Gijsreyn]

Summary of the Pull Request

Adds a new DSC v3 resource, profile (Microsoft.PowerToys/KeyboardManagerProfile), to PowerToys.DSC.exe that makes Keyboard Manager key and shortcut remappings deployable via dsc.exe and winget configure. Until now, DSC only controlled whether Keyboard Manager is enabled — the actual remappings could only be created through the Keyboard Manager editor UI.

Remappings are authored with friendly, layout-invariant key names instead of raw virtual-key codes:

resources:
  - name: Deploy key remappings
    type: Microsoft.PowerToys/KeyboardManagerProfile
    properties:
      profile:
        keys:
          - { from: CapsLock, to: Esc }
          - { from: Insert, to: Disable }
        shortcuts:
          - { from: "Ctrl+Shift+A", to: "Ctrl+V" }
          - { from: "Win+O, K", toText: "chord-triggered text" }
          - { from: "Ctrl+Alt+N", to: "Ctrl+S", targetApp: "notepad.exe", exactMatch: true }

The resource supports get/set/test/export/schema/manifest, applies replace-whole-profile semantics (declarative desired state), writes the exact profile encoding the C++ editor produces, and signals a running Keyboard Manager engine to reload the remappings immediately, meaning no PowerToys restart is required.

PR Checklist

• Closes: [KeyboardManager] [New-Feature] Keyboard Shortcuts deployable with DSC #38233
• Closes: [KBM] Exporting and loading Key remap file / presets  #4452 (export/import of remapping configurations is covered by export + set)
• 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 (new strings added to PowerToys.DSC Resources.resx; generated DSC manifest descriptions are deliberately not localized, matching the existing settings resource)
• Dev docs: Added/updated (doc/dsc/profile-resource.md, doc/dsc/overview.md, doc/dsc/modules/KeyboardManager.md, doc/devdocs/core/settings/dsc-configure.md)
• New binaries: Added on the required places — n/a: no new binaries; the resource lives in the existing PowerToys.DSC.exe. The additional generated manifest (microsoft.powertoys.KeyboardManager.profile.dsc.resource.json) is picked up automatically by the installer's unfiltered DSCModules\ component glob (generateAllFileComponents.ps1)
  • JSON for signing for new binaries — n/a
  • WXS for installer for new binaries and localization folder — n/a (verified generated component expansion includes the new manifest)
  • YML for CI pipeline for new test projects — n/a: tests were added to the existing PowerToys.DSC.UnitTests project
  • YML for signed pipeline — n/a
• 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

As remarked by @AmelBawa-msft on the issue, rempapings don't live in settings.json. They're stored in a separate profile file: %LOCALAPPDATA%\Microsoft\PowerToys\Keyboard Manager\<activeConfiguration>.json. The only KBM properties that reference it in settings.json are marked [CmdConfigureIgnore] ((activeConfiguration, keyboardConfigurations).

The legacy PowerShell-based PowerToysConfigure (v2/winget 0.2 schema) path was deliberately not chosen. It drives settings through a scalar PowerToys.Settings.exe set <Module>.<Property> <value> protocol; nested lists only work through the special-cased setAdditional side-channel, which merges by a Name key into the module's settings.json and cannot target the separate profile file. Its Set() also would have killed, requiring a restart for PowerToys.

The style is also in friendly strings and not in HotkeySettings-stylish, as the shape couldn't express what remappings it needed.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[AmelBawa-msft]

Since the DSC implementation is currently depending on shared Keyboard Manager/UI code, I think it’s worth reconsidering this model change. The safer design may be for DSC to own its own storage/model types and translate to the shared library shape only where needed, rather than expanding the shared model for DSC-specific needs. I’m not a maintainer on this area, but my guess is the team may prefer keeping DSC-specific augmentation isolated from the shared library contract