fix(bundle): Take cloud-hypervisor v54.0 and the urunc that names the disk image type

[pmoust]

This patch moves the bundle to cloud-hypervisor v54.0, and pins urunc at the commit v54.0 needs.

cloud-hypervisor v50.0 offers the virtio-net offloads by default and writes a guest's virtio-net header to the tap unchanged. That is the guest side of PwnEscape (https://pwn.ai/blog/pwnescape), the Linux host-kernel bug in deferred checksum completion (upstream fix 6785011f8b16). v54.0 turns offload_csum, offload_tso and offload_ufo off by default, and drops a transmit chain whose header asks for an offload the guest did not negotiate. So a Linux host running the bundle is no longer exposed through it, even before its kernel carries the fix.

Changes

• cloud-hypervisor v54.0 from monitors-build v0.1.1. Its cloud-hypervisor binaries match the upstream v54.0 static binaries byte for byte on both arches. virtiofsd and firecracker are unchanged. solo5 is still v0.12.1, rebuilt.
• New monitors-build naming. Releases are now tagged vX.Y.Z (MONITORS_RELEASE), and the per-arch tarball is <fingerprint>-<arch>.tar.gz. The layout inside is the same (urunc/bin/*). monitors-build publishes no checksums, so each tarball is pinned by sha256, the way cosign is.
• urunc at 0b1ef07, the head of feat/unchanged_containers-exec-fixes, now rebased onto urunc v0.8.1. It passes image_type=raw on every --disk (fix(cloud-hypervisor): Name the disk image type urunc-dev/urunc#1117). v54.0 removed image type autodetection and refuses a --disk without it.

The two pins go together, which is why this is one commit. urunc alone breaks a block-device rootfs on v50.0, which does not know image_type. v54.0 alone refuses the old urunc's --disk.

What changes for guests

• Network: no offloads, so a guest computes its own checksums and sends MTU-sized packets. On nofire-cerno this did not cost throughput: 1.3 GB/s down and 0.5 GB/s up on a system install, ~700/250 MB/s through rootless slirp.
• Disks: brig's own sandboxes never pass --disk to cloud-hypervisor. urunc prefers virtiofs for a container boot, even on devmapper. The image_type change matters for urunc-native images on devmapper.

Tested (amd64, nofire-cerno)

• Rootless upgrade from rc15, and a system install: boot, exec stdin/stdout up to 64 MiB, virtiofs, stop/restart, 4 parallel sandboxes, --cpus, isolated network, claude --version. All pass. Cold boot is ~0.95 s (1.8-9 s on rc15).
• devmapper end to end with busybox-cloud-hypervisor-linux-raw. rc16 boots. rc16's urunc on v54.0 fails with ImageTypeRequired. This bundle boots with --disk ...,id=rootfs,image_type=raw.
• A build pointed at the old v0.1.0 tarball stops at the pin with monitors hash mismatch.
• sh -n and shellcheck -S warning are clean.

Not tested: arm64. Its tarball pin is computed from the published release asset.

Known and not new (rc16 behaves the same): the claude profile on CONTAINERD_SNAPSHOTTER=devmapper fails with "could not read the sandbox's mount table", and a guest's exit status still comes back as 1.

Release sequence

1. Merge this and cut a bundle release.
2. Bump RUNTIME_VERSION in brig's install.sh to that tag.

[ananos]

@pmoust I took this over to keep it to one PR. monitors-build v0.1.1 now carries cloud-hypervisor v54.0, byte-identical to the upstream static binaries, so the bundle takes it from there again. The urunc pin moves to 0b1ef07 in the same commit, for image_type=raw (urunc-dev/urunc#1117). v54.0 refuses a --disk without it, so the two pins go together. You stay the author. Tested on amd64: rootless and system installs, plus devmapper end to end. Thanks for catching this!