VM artifact: fix root UUID and virtio bootstrap stream handling

[castrojo]

The published v25.08.14 donate-clanker VM artifact is not bootable through the current QEMU control-channel contract.

Observed with donate-clanker-vm-25.08.14-x86_64.raw:

• EFI /loader/entries/fdsdk.conf embeds root=UUID=9e71ad99-5ddc-5b20-8b9c-f3f6b4e570e1.
• The actual ext4 root filesystem UUID is a5e5b74b-7aa6-58b1-8408-e4147a36da17, so the guest stalls on dev-disk-by-uuid-9e71ad99....
• After correcting that UUID in a temporary copy, /usr/libexec/donate-clanker-bootstrap fails with File or stream is not seekable because it opens /dev/virtio-ports/org.projectbluefin.donate-clanker.bootstrap using Python open(..., "r+", encoding="utf-8"). Virtio ports are non-seekable streams.

Please regenerate the raw artifact with a matching root UUID and update the guest bootstrap implementation to use non-seekable-safe binary/read-write stream handling. The launcher now bounds and reports this handshake failure, but must not mutate the signed external image as a workaround.

Release: https://github.com/projectbluefin/fsdk-containers/releases/tag/v25.08.14

[castrojo]

Additional validation on 2026-07-31:

• The newer workflow artifact from run 30641329478 (source c0a283e, binary virtio-channel fix) still pins the guest worker to donate-clanker commit 96cc69f and only installs worker.source under /etc/donate-clanker. It does not install the required goose.yaml or local-agent-policy.md files.
• A disposable local copy patched with the current worker (including DONATE_CLANKER_* -> HIVE_*/AGENT_BACKEND mapping) plus those two config files boots through the current ujust donate path, receives control_ack, and stays up without the bootstrap service failure.
• The raw release asset remains unsuitable for mutation; the fix belongs in the guest build inputs and then a signed release artifact.