fix: speed up updates and show progress

[frahlg]

What

• Skip the full history backup when the current and target releases use the same database schema.
• Keep a full backup for a missing, invalid, or changed schema.
• Show live backup, download, restart, and health-check progress in both update dialogs.
• Keep status fresh during long Docker work and resume an active update after a page reload.
• Keep older updater sidecars from reporting a valid slow pull as failed after five minutes.
• Set file ownership during Docker COPY so each release no longer adds a duplicate full-app layer.

Measured

On the .40 host, the v1.10.5 update took 2m35s: about 2m10s for the 1 GB database backup, 9s to pull, 5s to recreate, and 11s to confirm health. A same-schema update now skips that 2m10s step. The new arm64 test image is about 19.3 MB compressed and removes the prior 14.8 MB duplicate layer.

The first update to a release with schema metadata still takes a full backup. Later same-schema updates use the fast path. Database format changes still require the full rollback backup.

Tests

• make verify-all
• npm test (80 tests)
• focused Go updater, API, state, and self-update tests
• release workflow policy and YAML checks
• arm64 Docker build and layer check
• pre-commit make verify
• pre-push make verify-all

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 16465c0b66

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Limit the legacy stale grace to pulls

When a current rollback/component_rollback path (for example go/cmd/ftw-updater/main.go:653, :949, :957) or an older updater reaches restarting/restoring without phase_started_at, this case gives it the two-hour legacy pull grace period. Those phases are not two-hour pulls (component image restore is bounded by 10 minutes and soft rollback by 30 minutes), so if the updater dies after stopping/copying/starting the service, /api/version/update/status remains in-flight for up to two hours instead of unblocking the UI as failed. Limit the 2h legacy threshold to pulling, or add phase heartbeats/state-specific thresholds for restore/restart.

Useful? React with 👍 / 👎.