ateom-microvm: reseed the guest CRNG on restore

[eliranw]

What

On the microVM restore path, ateom reseeds the guest kernel CRNG with fresh entropy through the kata-agent's ReseedRandomDev RPC, right after the guest resumes.

This implements the guest RNG reseed on restore that #1449 calls out as an unfiled gap (its Strategy 2, inject freshness at restore). Scoped to the kernel CRNG on the microVM runtime, so it does not close #1449.

Why

Two actors restored from the same snapshot start with the same frozen CRNG state. The kernel reseeds from ambient entropy on its own, but not immediately. Measured on a live restore, two clones kept returning identical /proc/sys/kernel/random/uuid values for up to about 36ms after resume before that happened. A workload reading randomness in its first moments after resume can land in that window and get duplicate values across clones.

Cloud Hypervisor has no VmGenID device to signal the guest, so ateom reseeds it directly. On each restore it hands a fresh 32-byte nonce to the kata-agent, which mixes it into the guest CRNG. The nonce differs per restore, so clones diverge regardless of the kernel's own timing. The kata-agent already exposes this RPC, so the change is host-side in ateom.

Behavior

Fires on every restore (golden cold-start and resume alike). Cold boot does not need it. Best-effort: a failure is logged, not fatal, so a transient agent error never fails an otherwise good restore.

Scope and limits

• Covers the kernel CRNG only. A workload's own userspace PRNG seed lives in the checkpointed app memory and stays a workload concern (Strategy 5 in Golden snapshot state pollution - general problem #1449).
• The reseed runs just after Resume, through the kata-agent, so it lands a few milliseconds after the vCPUs resume. In the live test the reseeded window shrank from about 36ms to about 6ms but did not reach zero. The first read or two after resume can still be frozen before the reseed lands. Fully closing it needs freezing the workload cgroup across the reseed, or a VMM VmGenID that acts before the vCPUs resume. A TODO in the code points at the VmGenID path once Cloud Hypervisor gains the device. Left as a follow-up.
• microVM runtime only. gVisor reads getrandom and urandom live from the host with no checkpointed RNG state, so restored gVisor sandboxes already get fresh entropy.

Testing

• Unit test on the nonce generator (length, and that two nonces differ).
• Verified live on a GKE microVM cluster with a workload that continuously records /proc/sys/kernel/random/uuid, so the restore instant is observable. Two clones from one golden snapshot were compared. Stock ateom returned identical CRNG output for up to about 36ms (7 consecutive reads) after resume, varying run to run. With this change the shared window shrank to about 6ms (1 read), then diverged.