feat(settings): user-controllable automatic update settings

[M3NT1]

Why

Dayflow currently ships with SilentUserDriver configured so Sparkle silently auto-installs every update — no prompt, no opt-out, no changelog. Combined with SUAutomaticallyUpdate = true in Info.plist, the user has zero control over when the app upgrades itself.

This PR adds a user-controllable update preference, following the pattern of the other toggles in the Settings "App preferences" section: a SettingsToggle bound to an @Published mirror of a SPUUpdater property, written back through an explicit setter (the only path the UI uses — see the Sparkle docs note below).

This is a re-submission of #351 (closed because the same changes were folded into the bundled #347; #347 is now being split back out so this feature can be reviewed on its own merits).

What changes

3 commits, all on feature/auto-update-toggle (branched from main @ 8944d27):

1. feat(updater): expose Sparkle update controls via UpdaterManager

• Adds @Published private(set) var automaticallyChecksForUpdates (mirror of SPUUpdater.automaticallyChecksForUpdates)
• Adds @Published private(set) var automaticallyDownloadsUpdates
• Adds @Published private(set) var canCheckForUpdates — the "Check now" button binds to this to dim itself while Sparkle is mid-check
• Adds @Published var pendingReleaseNotesURL: URL? — captured from SUAppcastItem.releaseNotesURL in didFindValidUpdate, cleared on no-update cycles
• All four are populated by KVO observers in setupObservers() (.initial + .new), so the UI reflects the user's saved preference from the previous session on launch
• Explicit setters setAutomaticallyChecksForUpdates(_:) / setAutomaticallyDownloadsUpdates(_:) write through SPUUpdater directly — per the Sparkle docs requirement that these properties only be set in response to a user setting change. This is what makes the change persist to NSUserDefaults.
• openReleaseNotes() opens the captured release-notes URL in the default browser

2. fix(updater): respect user update preference in SilentUserDriver

• SilentUserDriver gains an automaticallyChecksForUpdates flag, kept in lockstep with SPUUpdater via the KVO observer in UpdaterManager
• showUpdateFound now branches on that flag:
  • On → .install (silent install, same as today's behavior — no regression)
  • Off → .dismiss (caches the release-notes URL so the user can review and install manually via the "View changelog" link in Settings, but the update is never pushed onto them)
• The user-controlled toggle takes effect on the very next update check, even if Sparkle's 2nd-launch permission prompt is skipped

3. feat(settings): add update controls to Other tab

New "Updates" section in SettingsOtherTabView:

Control	Behavior
Toggle: "Automatically check for updates"	Binds to automaticallyChecksForUpdates mirror; writes through setAutomaticallyChecksForUpdates
Sub-toggle: "Automatically download and install updates"	Binds to automaticallyDownloadsUpdates; disabled when auto-check is off
"Check now" button	Routes through SPUStandardUpdaterController (not SilentUserDriver) so the user always gets the standard Sparkle release-notes UI even when auto-update is off; dims via canCheckForUpdates while a check is in flight
Status subtitle	"Latest version" / "Update available: v2.2.0" / "Checking…" / "Update needs authorization"
Conditional "Latest release notes" row	Appears only when pendingReleaseNotesURL is set; "View changelog" button opens it in the default browser

Design notes

• No new files — the three touched files already existed; this only extends them.
• No behavior change by default. SilentUserDriver.automaticallyChecksForUpdates defaults to true, matching today's silent-install behavior. Users who never touch the new toggle see no difference.
• KVO, not polling. The @Published mirrors are driven by NSKeyValueObservation on the SPUUpdater properties, so the UI updates instantly when Sparkle changes a value internally (e.g. the 2nd-launch permission prompt).
• Sparkle docs compliance. The setters write through SPUUpdater.automaticallyChecksForUpdates / automaticallyDownloadsUpdates rather than the @Published mirrors, because the docs state: "Only set this property if the user wants to change the default via a user settings option."
• Analytics. Each setting change emits a sparkle_setting_changed event with the setting name and new value; update lifecycle events (sparkle_check_triggered, sparkle_update_found, sparkle_update_not_found, sparkle_cycle_finished, sparkle_install_*) are already wired in the existing delegate methods.

Files

 Dayflow/Dayflow/System/SilentUserDriver.swift      | 20 ++++-
 Dayflow/Dayflow/System/UpdaterManager.swift        | 89 +++++++++++++++++++++++
 Dayflow/Dayflow/Views/UI/Settings/SettingsOtherTabView.swift | 65 ++++++++++++++++
 3 files changed, 171 insertions(+), 3 deletions(-)

Test plan

• Builds clean on Dayflow v2.1.0 (Xcode 26.6, arm64)
• Installed at /Applications/Dayflow.app, Apple Dev signed, launches without crash
• Toggle state persists across app relaunch (via Sparkle's NSUserDefaults storage)
• When auto-check is on, updates still install silently (no regression)
• When auto-check is off, "Check now" surfaces the standard Sparkle update UI with release notes
• "View changelog" opens the release-notes URL in the default browser
• "Automatically download and install" sub-toggle is disabled when auto-check is off

Tested with Claude Code 2.1.22.

Relationship to other PRs

• Supersedes feat(settings): add user-controllable update settings #351 (closed — same branch, same changes; re-opened here as a standalone reviewable PR).
• The bundled fix(ai, daily, chat-cli): bundled v2.1.0 fixes #347 also contains these 3 commits alongside unrelated fixes; this PR isolates the update-settings feature so it can be reviewed and merged independently.