Investigate a winget package for Windows

[soloturn]

AI-assisted issue. Filed by agent driven by @soloturn via GDD.

Context

Follow-up to #5351 (the Homebrew tap for macOS). Windows users have no equivalent winget install path today - only the launcher, a direct-download zip, or now Homebrew on macOS.

Problem / Current State

winget doesn't work like Homebrew taps or the AUR. There's exactly one official repo, microsoft/winget-pkgs - no lightweight self-hosted equivalent of a Homebrew tap. Getting a package listed means submitting a manifest PR there, which goes through mandatory automated checks (schema validation, installer hash/URL checks, a live Defender antivirus scan, silent-install testing in a sandboxed VM) and manual moderator review. Microsoft's own docs state they can refuse a submission for any reason. winget does support third-party "sources," but those require hosting a REST-API-compliant server per Microsoft's spec, not just a git repo - not a realistic AUR/tap substitute.

There's also a packaging-fit problem: winget manifests are static YAML with no equivalent of a Homebrew cask's preflight script. The current Windows build (TerasologyOmega.zip: jars, natives, a .bat launcher, no installer) can't be wrapped into something more "installed" the way the macOS cask's preflight step builds a real .app bundle at install time. winget does support zip-based "portable" installers (manifest schema 1.4+, NestedInstallerType/NestedInstallerFiles) as the closer fit, or a real installer could be built separately (WiX/Inno Setup) - both are real engineering work beyond writing a manifest.

Acceptance Criteria

• Decide whether to pursue: a portable-zip winget manifest against the existing TerasologyOmega.zip (fastest, least install-experience polish), a real installer (WiX/Inno Setup wrapping the same zip, closer to a normal Windows install), or defer
• If pursuing: a manifest (PackageIdentifier likely MovingBlocks.Terasology or TerasologyFoundation.Terasology) passes winget validate and the Windows Sandbox test locally
• Submission PR opened against microsoft/winget-pkgs and merged
• winget install <id> verified working end to end
• Update path decided: manual manifest bump per release, or automate via wingetcreate / winget-releaser in CI - every version still needs its own manifest folder + PR (winget has no "always latest" source concept at all), but unlike Homebrew's terasology-latest-bin (which has to skip verification with sha256 :no_check), the Omega build has a real, stable version identifier and a real checksum to pin each time (see Technical Notes) - CI could auto-file a new manifest PR per Omega build number

Technical Notes

• No org registration is required to submit to winget-pkgs - individuals and projects submit under their own or a project name today. "Is this possible for an org like Terasology Foundation" is really "can we pass the review bar," not "do we need special account status."
• The Omega CI build is rolling but not anonymous: .../lastSuccessfulBuild/buildNumber returns a real, stable build number for whatever's newest (e.g. 25 as of this writing) - each build's own artifact directory is a permanent, numbered URL, e.g. build 24's, with a sha256sums.txt giving a real checksum for that build's TerasologyOmega.zip. So unlike Homebrew's terasology-latest-bin (sha256 :no_check, no fixed version), a winget manifest tracking the rolling build could still pin a genuine PackageVersion (the build number) and a genuine InstallerSha256 each time - just needs re-submission on every build, which is what the automation bullet above is for.
• Reference: terasology cask for what the existing zip contains and how it's currently unpacked/wrapped on macOS.

Related

• See Transfer soloturn/homebrew-terasology tap to MovingBlocks org #5351 (Homebrew tap, the macOS equivalent this follows up on)