fix: stabilize microVM clocks and concurrent actor startup

[EItanya]

Cloud Hypervisor v53 corrects the guest's kvm-clock across restore, but our amd64 guests selected tsc and resumed 3–14 seconds behind the host. Backport agent-substrate#1945 to select clocksource=kvm-clock for amd64 guests. ARM64 keeps its existing clock configuration; v53 handles its clock correction through cloud-hypervisor/cloud-hypervisor#8343. Existing amd64 golden snapshots must be recreated to adopt the boot argument.

The RNG fix from agent-substrate#1524, including mandatory reseeding and reuse of one Kata connection, is already in this fork's main.

Also fix the shared sysctl race exposed by this PR's gVisor E2E run. Concurrent actor starts use different network namespaces but share the /proc/sys mount. One call can remount it read-only while another is writing, causing actor startup to fail with EROFS; overlapping writes can also prevent the read-only remount. Serialize the entire write/remount sequence. The regression uses real network namespaces and a private mount namespace so it leaves the host untouched.

Validation:

• The sysctl regression failed all 10 runs against the original helper and passed 20 runs with the fix and race detection.
• Networking race tests, the full root-gated suite with race detection, and make verify passed.
• Earlier local kagent validation of the RNG and clock fixes on amd64 passed the full microVM suite (185 cases, 10 existing skips), followed by 24 repeated checkpoint/fork and timeout cases after the RNG review fixes. Clock differences with kvm-clock stayed within about 0.21 seconds. These runs used the previous fork base; they have not been rerun on the newly synced base.

Related: kagent-dev/kagent#3004. CI still needs a Substrate release containing the fixes.

• Tests pass
• Appropriate changes to documentation are included in the PR