Sign Windows desktop releases

[bholmesdev]

Problem

Windows desktop releases are currently unsigned. Direct downloads can show Unknown publisher or Microsoft Defender SmartScreen warnings, and unsigned releases cannot carry publisher reputation across versions.

This is separate from WinGet distribution in #179: WinGet improves discovery, installation, and upgrades, but does not sign Hubble artifacts or establish a verified publisher identity.

Proposed work

• Choose a trusted signing provider and publisher identity (consider Microsoft Artifact Signing or SignPath Foundation for open source)
• Sign x64 and arm64 NSIS installers in the Windows release job
• Verify signatures before publishing GitHub Release assets
• Document signing prerequisites and secret/certificate rotation
• Confirm the installed app and uninstaller carry the expected publisher identity

Acceptance criteria

• Published Windows installers have a valid Authenticode signature
• Windows displays the chosen verified publisher instead of Unknown publisher
• CI fails before publishing if signing or signature verification fails
• Signing applies consistently to every Windows release

Related to #179.

[github-actions]

Routing this to Needs discussion. The problem is real and well-described — Windows installers from the release job are unsigned, so users hit Unknown publisher / SmartScreen warnings — but the work is blocked on an open decision plus external provisioning that an implementer can't resolve in one pass.

Codebase evidence:

• The Windows release job in .github/workflows/desktop-release.yml builds and publishes via electron-builder --win with no signing step or certificate secrets, confirming installers are unsigned.
• apps/desktop/package.json targets NSIS for win (x64 + arm64), so the issue's reference to NSIS installers is accurate.
• macOS signing/notarization already exists in the same workflow (CSC_LINK, CSC_KEY_PASSWORD, APPLE_ID, etc.), so there is a pattern to model from once a Windows identity is chosen.

Why discussion first:

• The first proposed step — choosing a signing provider and publisher identity — is a product/ops decision (cost, EV vs standard cert, Azure Trusted Signing vs SignPath Foundation for OSS) that shapes the whole implementation.
• It depends on obtaining a certificate/account and provisioning CI secrets, which must happen out-of-band by a maintainer before CI work can land.

Open questions to resolve before implementing:

• Which signing provider and publisher identity? (Azure/Microsoft Artifact Signing, SignPath Foundation, or a traditional OV/EV cert?)
• Who owns acquiring the certificate/account and adding the CI secrets?
• Should signing block the release (fail CI on missing/invalid signature) or degrade gracefully like the macOS job does when CSC_LINK is absent?
• Is arm64 Windows signing in scope for the initial pass, or x64 first?