Add Managed SLS Update/Upgrade Flow

[Yeetoxic]

Summary

Add an SLS-managed update flow so operators can safely upgrade Protocube, daemon, software definitions, and related runtime assets without manually editing compose files, pulling images, or restarting services by hand.

This was discussed alongside the install lifecycle work, but it is separate from daemon-owned install/warmup behavior and should be tracked independently.

Problem

Today, local and production upgrades are mostly manual:

• pull or build newer images;
• update compose files or tags;
• restart Protocube and daemon in the right order;
• verify node registration and heartbeats;
• reload software/blueprint definitions;
• manually check version banners and logs.

This is easy to get wrong, especially when Protocube and daemon need to stay compatible. During local validation we also had to manually notice when containers were one version behind.

Goals

• Provide a predictable update path for SLS components.
• Make current and target versions visible.
• Reduce manual restart/rebuild steps.
• Keep daemon/Protocube compatibility checks explicit.
• Make update failures observable and recoverable.

Non-Goals

• Do not combine this with install/warmup lifecycle logic.
• Do not silently update running production systems without operator action.
• Do not require all deployments to use Docker Compose.
• Do not replace normal release packaging or CI image publishing.

Proposed Capabilities

• Expose current component versions through API/CLI:
  • Protocube version;
  • daemon version;
  • vSLS/plugin version, if connected;
  • software definition revision, if available.
• Add an update check command or endpoint:

sls update check

• Report:
  • installed version;
  • latest available version;
  • compatibility notes;
  • required restart steps;
  • whether migrations or config changes are expected.
• Add an explicit update/apply path:

sls update apply

• For Docker/Compose environments, optionally support:
  • pulling new images;
  • rebuilding local images when requested;
  • restarting Protocube and daemon in a safe order;
  • waiting for daemon re-registration and healthy heartbeats.
• Add clear status and failure messages when update steps fail.

Acceptance Criteria

• Operators can see the current SLS component versions from one place.
• Operators can check whether updates are available without applying them.
• Applying an update is explicit and produces clear progress output.
• Protocube/daemon compatibility is validated before or during update.
• Failed updates leave enough logs/status to understand what happened.
• Existing manual Docker Compose workflows remain possible.