The update manager started in download-only mode and every engine stop
reset it there again, kicking the update loop with the cached latest
version. On a managed peer this published a "New version available"
notification on each disconnect, session expiry or logout, and once more
in the window between daemon start and the first network map. Users under
enforced updates then installed the release by hand.
Replace the boolean with a three-state mode. The manager starts undecided
and publishes nothing, from the fetcher or from NotifyUI, until the network
map picks download-only or managed. A new connection lifecycle resets to
undecided; disconnects leave the last decision untouched. A missing
AutoUpdateSettings now means download-only instead of a no-op, and on
platforms without an installer SetVersion falls back to download-only so
they keep notifying.
Auto-update logic moved out of the UI into a dedicated updatemanager.Manager service that runs in the connection layer. The
UI no longer polls or checks for updates independently.
The update manager supports three modes driven by the management server's auto-update policy:
No policy set by mgm: checks GitHub for the latest version and notifies the user (previous behavior, now centralized)
mgm enforces update: the "About" menu triggers installation directly instead of just downloading the file — user still initiates the action
mgm forces update: installation proceeds automatically without user interaction
updateManager lifecycle is now owned by daemon, giving the daemon server direct control via a new TriggerUpdate RPC
Introduces EngineServices struct to group external service dependencies passed to NewEngine, reducing its argument count from 11 to 4
Zoltán Papp