fix(restore): do not block on the Signal K start

[mairas]

Why

halos-marine-containers#194 orders marine-signalk-server-container.service behind a provisioning one-shot with TimeoutStartSec=infinity. A plain systemctl start waits for the whole start transaction, so it returns only once provisioning finishes.

Measured on a HALPI2 with a scratch unit pair of that shape (one-shot sleeping 45s, Requires=/After= it): plain start 45s, --no-block 0s.

halos-restore.sh runs on a freshly flashed device migrating from OpenPlotter, which typically has no uplink configured yet — exactly the state where provisioning waits. The restore would sit at a silent terminal partway through a data migration, and on_exit's recovery restart could hang the same way on the error path.

verify_signalk already polls for readiness, so nothing is lost by not blocking.

Note for reviewers

The provisioning marker lives at <data_root>/.provisioned while the restore replaces <data_root>/data, so it survives a restore: after migrating, the device keeps the backup's plugin set and does not re-provision the curated set until the next package upgrade. That is consistent with the gate being scoped to package transactions, but it is a deliberate consequence worth knowing — say so if the migration story should instead bring the device to the curated spec.

[mairas]

Correction to this PR's own justification.

I wrote "verify_signalk already polls for readiness, so nothing is lost." That is wrong, and a review caught it.

The poll is 30 × sleep 2 = 60s. Provisioning measures ~72s cold on a CM5 for the full curated set, with PACKAGE_TIMEOUT=180 per package and a retry backoff on top. So in exactly the scenario this PR exists for — a restore on a device that has not provisioned since its last upgrade — the poll expires while provisioning is legitimately still working, and the script reports "Signal K did not respond on :3000 within 60s" on a device that is fine. It then continues and can exit 0 with Signal K not yet up.

bf78537 fixes the reporting rather than the timeout: when the poll expires, it checks whether <pkg>-provision.service is still activating/active and, if so, says the plugin set is still installing and points at journalctl -fu. A genuine failure still warns as before.

Not extending the 60s wait is deliberate — provisioning has no deadline of its own, so any number picked here would be arbitrary, and the operator is at the terminal and better served by being told what is happening than by a silent multi-minute wait.