Publish managed and Native AOT variants through WinGet

## Summary

Publish both SharpTS Windows distributions through the WinGet Community Repository:

- Managed, self-contained SKU (full feature set)
- Native AOT SKU (faster startup with the documented Native AOT limitations)

The release workflow already produces and smoke-tests Windows x64 and ARM64 ZIP archives for both SKUs. This issue covers the remaining WinGet packaging, validation, initial submission, and update automation.

## Recommended package model

Create two separate WinGet package identities because WinGet cannot select between managed and Native AOT installers of the same architecture within one package:

| Distribution | Package identifier | Command |
| --- | --- | --- |
| Managed/default | `SharpTS.SharpTS` | `sharpts` |
| Native AOT | `SharpTS.SharpTS.NativeAOT` | `sharpts` |

The two packages should be documented as mutually exclusive. Keeping the same command preserves scripts and documentation when switching implementations. If side-by-side installation becomes a requirement, rename the Native AOT command to `sharpts-aot` instead.

## Existing release assets

Use the versioned GitHub Release ZIP assets already produced by `.github/workflows/publish.yml`:

- `sharpts--win-x64.zip`
- `sharpts--win-arm64.zip`
- `sharpts-native--win-x64.zip`
- `sharpts-native--win-arm64.zip`

Each archive contains a root-level `sharpts.exe`, `LICENSE`, and `README.md`. Both SKUs are standalone and should not declare a .NET package dependency in WinGet.

The initial submission must target a new successful tagged release with all four Windows assets. Do not target v1.0.8 because that release has no binary assets.

## Manifest design

For each package identity, create the standard multi-file manifest set:

- Version manifest
- Default locale manifest (`en-US`)
- Installer manifest

Installer configuration:

- `InstallerType: zip`
- `NestedInstallerType: portable`
- x64 and ARM64 installer nodes
- `NestedInstallerFiles.RelativeFilePath: sharpts.exe`
- `Commands: [sharpts]`
- Version-specific GitHub Release URLs
- SHA-256 for each ZIP
- MIT license, repository, package, and release-notes URLs
- Managed description emphasizes the full feature set
- Native AOT description clearly lists its managed-only limitations
- Use the WinGet Community Repository's recommended manifest schema at submission time

Leave `ArchiveBinariesDependOnPath` unset so WinGet uses its normal portable-command link behavior.

## Work items

- [ ] Run the existing `workflow_dispatch` release-matrix dry run before the next tag.
- [ ] Produce a successful tagged release containing all four required Windows ZIP assets.
- [ ] Decide whether to Authenticode-sign the Windows executables before packaging. Signing is recommended for SmartScreen reputation and security-scanner reliability, but is not required for a portable WinGet package.
- [ ] Create the initial `SharpTS.SharpTS` manifests with WinGetCreate.
- [ ] Create the initial `SharpTS.SharpTS.NativeAOT` manifests with WinGetCreate.
- [ ] Validate both manifest directories with `winget validate`.
- [ ] Install each package from its local manifest and verify `sharpts --version` plus a basic interpreter/compiler smoke test.
- [ ] Test PATH availability from a fresh terminal.
- [ ] Test uninstall cleanup for both packages.
- [ ] Test x64 and ARM64 installer selection.
- [ ] Test managed-to-Native-AOT and Native-AOT-to-managed switching.
- [ ] Test an upgrade between two package versions once an update manifest is available.
- [ ] Run the winget-pkgs `Tools/SandboxTest.ps1` validation for both packages.
- [ ] Submit separate initial PRs to `microsoft/winget-pkgs`, one per package identity.
- [ ] Complete Microsoft CLA/reviewer feedback and verify both packages after publication.
- [ ] Update the SharpTS README with the final `winget install --id ... -e` commands and the mutually-exclusive SKU guidance.

## Release automation

After both initial package identities are merged into `microsoft/winget-pkgs`:

- [ ] Add a downstream Windows job after the GitHub Release job.
- [ ] Run `wingetcreate update SharpTS.SharpTS` with the managed x64/ARM64 asset URLs.
- [ ] Run `wingetcreate update SharpTS.SharpTS.NativeAOT` with the native x64/ARM64 asset URLs.
- [ ] Submit the generated updates automatically.
- [ ] Store the classic GitHub PAT in `WINGET_CREATE_GITHUB_TOKEN` with the minimum required `public_repo` scope; do not pass it as a command-line argument.
- [ ] Gate automation until the initial package manifests have been accepted.
- [ ] Submit only stable tags. If preview releases are needed later, use separate `.Preview` package identities rather than WinGet channels.

## Acceptance criteria

- `winget install --id SharpTS.SharpTS -e` installs the correct native-architecture managed binary and exposes `sharpts` in a fresh terminal.
- `winget install --id SharpTS.SharpTS.NativeAOT -e` installs the correct native-architecture Native AOT binary and exposes `sharpts` in a fresh terminal.
- `sharpts --version` reports the package/release version for both SKUs.
- Install, upgrade, and uninstall work without interactive prompts or stale PATH entries.
- The Native AOT package description communicates its reduced feature surface before installation.
- Future stable GitHub releases automatically open WinGet update PRs for both identities only after all release assets have passed their existing smoke gates.