Story: Implement provisioner self upgrade subcommand downloading both CLI and daemon binaries

Part of epic #500 — Self-Upgrade Protocol.

Implement the `provisioner self upgrade` CLI subcommand — the **detached child** spawned by the daemon (HIP XXXX2 self-upgrade steps 2 → 3).

## Ownership split (HIP-authoritative — corrected)

Per HIP XXXX2 (lines 1581–1586), the responsibility is split — the previous "downloads both binaries" wording was wrong:

- The **daemon** downloads + verifies only the new **CLI** binary, then spawns this child (now tracked by #716).
- This **CLI child** (`provisioner self upgrade`) downloads + verifies the new **daemon** binary (HIP step 3c) and owns the remainder of the protocol (validate → archive → install → stop/start → health-check → success/recovery).

## Scope

- New `provisioner self upgrade --state-file=` subcommand.
- Read the state file to obtain `manifestPath` + the full `provisioner` block; re-read `infrastructure-versions.yaml` to confirm consistency (HIP step 3a).
- Download `solo-provisioner-daemon` for `provisioner.daemon.version` to `/tmp/solo-provisioner-daemon-v`; verify via #698's promote-gate (signature + manifest checksum); exponential-backoff retry, abort with `SelfUpgradeFailed` on exhaustion (HIP step 3c).
- Wire in the downstream steps owned by sibling stories: version-compat gate (#714), archive/install/stop/start (#526), health-check loop (#715), recovery (#528), state-file updates (#529), events (#530).
- Document the new command + flags in `docs/quickstart.md`.

## Acceptance criteria

- Does **not** re-download the CLI it is running from; downloads only the daemon binary.
- Daemon-binary download verified via #698 before install; failure leaves prior binary in place.
- `--state-file` is the sole input for version/checksum details (no per-value flags).