Roadmap: in-app updates for APW.app (Sparkle or equivalent)

[jmcte]

Context

APW.app today is updated via Homebrew (brew upgrade), manual download (once the DMG path lands), or rebuild-from-source. There is no in-app update channel, which means:

• Users not following GitHub releases run stale brokers.
• Security fixes have no push channel — only pull.
• Notarized release signatures are verified at install time but never re-checked at update time.

For a security-sensitive credential broker, "update urgency" deserves its own surface.

Proposed Fix

Evaluate Sparkle (the standard macOS in-app update framework) or a homegrown updater that:

• Checks a signed appcast served from a stable URL.
• Verifies the EdDSA signature of the appcast and the codesign + notarization status of the downloaded bundle before applying.
• Respects MDM-managed config (companion roadmap issue) so enterprise admins can disable user-driven updates.
• Surfaces an explicit "security update available" prompt when the appcast item is flagged.

Acceptance criteria

• Update mechanism chosen (Sparkle vs custom) and rationale documented.
• Appcast signed and served from a stable URL controlled by the project.
• Update flow verifies codesign + notarization before swap.
• MDM key documented to disable in-app updates.
• Security update surfacing is distinct from cosmetic updates.

[jmcte]

Material PR submitted: #81

Current status:

• Sparkle 2 is selected and documented as the update mechanism.
• The signed appcast contract, template, validator, release wiring, native Info.plist rendering, Sparkle linkage, and managed disable policy are implemented in the PR.
• CI is green on the PR.

Remaining acceptance proof before this issue should be closed:

• Run a signed/notarized update flow against the project release appcast and confirm the update verifies before swap.