feat: hub self-update capability

[zeroasterisk]

Problem

Updating the scion hub binary currently requires SSH access to the host VM, pulling the repo, building from source, and restarting the systemd service. This is a multi-step manual process that's hard to delegate to agents or automate.

Agents running inside containers have read-only mounts of /opt/scion/bin, no systemd access, and can't update the hub they're connected to — even with sudo.

Proposed Solution

Add a scion hub update (or scion self-update) command that:

1. Downloads the latest release binary (or builds from source if Go is available)
2. Replaces the running hub binary
3. Gracefully restarts the hub service
4. Verifies health after restart

Possible approaches

• Binary release download: If pre-built binaries are published (GitHub Releases, GCS bucket, etc.), download and replace. Similar to how rustup update or gh extension upgrade work.
• In-place rebuild: If the source repo is available on the host, git pull && go build && install. The gce-start-hub.sh script already does this — expose it as a CLI command.
• Hub API endpoint: Add a /admin/update endpoint to the hub that triggers the update from the server side. Agents could call this via the hub API without needing host access.
• Container image update: For containerized deployments, trigger a rolling update of the container image.

Agent-initiated updates

Ideally, an agent should be able to trigger a hub update via:

scion hub update --non-interactive

This would call the hub API, which handles the actual binary swap and restart on the host side.

Context

Current setup: GCE VM running scion hub as systemd service. Agents run in containers with read-only binary mounts. The agent container has Go, git, and sudo but can't write to /opt/scion/bin (read-only mount) or access systemd.

The scripts/starter-hub/gce-start-hub.sh script handles the build+restart flow but must be run from the host, not from inside an agent container.