winget: make the first winget-pkgs submission and turn on the winget-publish job

[jonassaa]

The last remaining piece of #187, split out and deliberately deferred. Everything
winget needs inside this repository already landed — what is left is entirely manual
work outside it, plus a wait on a Microsoft moderator. Nothing here blocks any other
work, and the release pipeline is already correct in its absence.

Already shipped — do not rebuild it

• release.yml → winget-publish — vedantmgoyal9/winget-releaser@v2, identifier
  JonasAasberg.PlatypusGit, installers-regex pinned to the .msi (the action's
  default also matches .exe/.msix/.appx, and the release attaches a portable
  .zip that installs nowhere and registers no ARP entry). Same
  prerelease == false gate as bump-cask / bump-scoop / apt-publish, copied
  rather than retyped, so a prerelease can never reach the catalogue every winget
  user sees.
• scripts/winget-wizard.sh — walks the six steps that live outside this repo
  (Microsoft CLA, fork of microsoft/winget-pkgs, Komac, the first submission, a
  classic PAT, the repo secret). Idempotent and interactive on purpose; never pipe it
  into a shell.
• docs/dev/distribution.md — "The winget package" and "The MSI's registry
  identity — pinned for winget": UpgradeCode is pinned and the manifest repeats it,
  ProductCode can never be hard-coded (Tauri's main.wxs uses <Product Id="*">, so
  Komac must read it out of the released .msi), and the manifest is Scope: machine
  because the bundler hardcodes InstallScope="perMachine".

Current state, verified 2026-09-07

• gh secret list has no WINGET_TOKEN.
• microsoft/winget-pkgs → manifests/j/JonasAasberg is 404.

So winget-publish no-ops on every release, by design: the presence of the secret is
the signal "the manual submission happened". A release log line reading
WINGET_TOKEN is not set — skipping the winget submission is the expected state today,
not a broken release — see docs/dev/releasing.md's "jobs that succeed by doing
nothing".

The gate is a step, not the job's if: — the secrets context is not available in
a job-level condition, so gating there would be false forever and the job would never
run at all. Don't "simplify" it.

What is actually left

1. Run sh scripts/winget-wizard.sh and complete its six steps. The first submission
   needs no PAT: the wizard borrows gh auth token, whose repo scope is a superset of
   public_repo.
2. Then wait — the winget-pkgs pull request goes through a 10-step validation
   pipeline and then a human moderator. Nothing can hurry that, and the package is not
   installable until it merges.
3. WINGET_TOKEN must be a classic PAT with public_repo. Fine-grained tokens
   cannot open a PR against winget-pkgs, and that failure reads as a permissions error
   rather than a wrong-token-type one. It is deliberately not the GitHub App that
   bump-cask / apt-publish mint from — those push to repos we own, this opens a PR
   from a personal fork of a Microsoft repo.
4. The installer URL must be tag-pinned, not releases/latest/download/… the way
   site/src/data/site.ts is. Validation hashes the file, and a vanity URL whose bytes
   change under it fails every existing manifest.

Code signing is NOT the blocker — and the README still says it is

docs/dev/distribution.md establishes this: winget-pkgs policies mandate signing for
MSIX only (Windows will not install an unsigned one); there is no such rule for an
.msi. The SmartScreen reputation check in the validation pipeline applies to the
installer URL — ours is a GitHub release URL — not to the binary's signature. A
certificate is still worth having; it was just never the winget blocker.

Two README.md claims contradict that and should be corrected when this is picked up
(both also link to the now-closed #187 and need repointing here):

• "There is still no winget package (One-line install + package-manager updates on Linux (and a CLI install on Windows) #187): it needs a code-signing certificate more
  than it needs code."
• Status bullet: "No winget package yet — that one really does wait on the code
  signing above, which is what separates it from Scoop (One-line install + package-manager updates on Linux (and a CLI install on Windows) #187)."

The thing that separates winget from Scoop is not signing — it is that the first
submission is a manual PR into a Microsoft-owned repository behind a moderation queue,
whereas the Scoop bucket is a repo we own.

Recorded elsewhere, explicitly not in scope here

arm64 Windows, .rpm + a dnf repo, and an AUR platypusgit-bin PKGBUILD — all in the
apt/Scoop specs' follow-ups. Chocolatey stays skipped unless someone asks.