doctor: install the cocoonstack fork builds of cloud-hypervisor and the firmware

[CMGS]

Why

cocoon-check --upgrade installed upstream Cloud Hypervisor v53.0, which has no CopyOnWrite memory restore. cocoon's default clone/restore mode is mmap, which maps to exactly that mode, so a doctor-provisioned host rejects every default clone with a 400 from vm.restore. The cocoonstack fork dev release build (upstream main plus diff snapshots and the QCOW cluster-leak fix, cloud-hypervisor v54.0.0) has it. The firmware fork carries the EFI ResetSystem and IA32_FEATURE_CONTROL/VMXON-lock fixes that Windows guests need, and the docs already told people to use both forks by hand.

What

• doctor/check.sh --upgrade installs cloud-hypervisor-<arch> from the cocoonstack/cloud-hypervisor release tag CH_REF (default dev) and, on x86_64, hypervisor-fw from the cocoonstack/rust-hypervisor-firmware tag FW_REF (default dev). Both downloads are verified against the published SHA256SUMS / .sha256 before install, and the FIXED line records the build commit from the release's build-info.json.
• ch-remote (CH_REMOTE_VERSION, v53.0 — the fork release ships no ch-remote asset), Firecracker (FC_VERSION, v1.16.1), the aarch64 firmware (FW_VERSION, 0.5.0 — the fork publishes x86_64 only) and the CNI plugins stay on upstream releases.
• The check pass fails a cloud-hypervisor older than v54 with the reason (no CopyOnWrite restore, default mode rejected) instead of passing a host that cannot clone.
• docs/install.md and docs/windows.md state what the forks actually carry today. The DISCARD and virtio-net ctrl_queue fixes the Windows page attributed to the fork are upstream (v51.0 / v52.0); the fork's own delta is diff snapshots and the QCOW fix.

No cocoon code change: a CH that rejects CopyOnWrite already fails loud (PUT vm.restore → 400: <CH body> through utils.DoAPI), and a silent fallback to copy would be the ~6x restore-latency regression the restore code refuses by design.

Evidence

• bash -n doctor/check.sh clean; shellcheck -S warning reports only the pre-existing SC2034 (prefix_len, untouched).
• --upgrade run in debian:bookworm-slim containers on both architectures (COCOON_*_DIR under /tmp, curl + libcap2-bin only):

# linux/arm64 (native)
==> Install cloud-hypervisor (cocoonstack fork dev)
  [FIXED] cloud-hypervisor dev (commit 815f40b5) -> /usr/local/bin/cloud-hypervisor
==> Install ch-remote v53.0 … [FIXED]
==> Install firecracker v1.16.1 … [FIXED]
==> Install hypervisor-fw 0.5.0
  [FIXED] hypervisor-fw 0.5.0 -> /tmp/cocoon/firmware/CLOUDHV.fd
==> Install CNI plugins v1.9.1 … [FIXED]
20fa683ac2626b97efabdbaae300b5119699aaf9f558c81108c8bce7bbda5e2c  /usr/local/bin/cloud-hypervisor   (= SHA256SUMS cloud-hypervisor-aarch64)

# linux/amd64 (emulated)
==> Install cloud-hypervisor (cocoonstack fork dev)
  [FIXED] cloud-hypervisor dev (commit 815f40b5) -> /usr/local/bin/cloud-hypervisor
==> Install hypervisor-fw (cocoonstack fork dev)
  [FIXED] hypervisor-fw dev (commit 4161be33) -> /tmp/cocoon/firmware/CLOUDHV.fd
0bd06a827ee943185c11142f04406380d8240f6ae3668e49aa4089cca9055064  /usr/local/bin/cloud-hypervisor   (= SHA256SUMS cloud-hypervisor-x86_64)
b53d0a7492ac4cdbac1c5d6a05acd53e8d96e71b955720a20171b026383fce9c  /tmp/cocoon/firmware/CLOUDHV.fd   (= hypervisor-fw.sha256)

• The same fork builds (cloud-hypervisor v54.0.0 815f40b) drove cocoon master on the bare-metal testbed today: vm run, vm net --nics 2, vm disk attach/detach, stop and rm all clean (cocoon-specs tests/2026-09-05-fc-hotplug-mtu-parity.md).