ateom: prepare gVisor sandbox during image pull

[Du Bin (dubin555)]

Related to #968.

This implements the cold-start portion of the issue. Restore paths are intentionally unchanged because FULL and DATA_ON_GOLDEN restore boot from a memory image, and DATA restore has different dependencies.

Summary

• split atelet OCI preparation into shared prerequisites, pause-bundle preparation, and application-bundle preparation
• start gVisor network and pause/root sandbox setup as soon as the runtime asset and pause bundle are ready, in parallel with application image preparation
• add internal PrepareSandbox and DiscardPreparedSandbox RPCs, including idempotency, request matching, and retryable partial cleanup
• preserve actor CPU and memory limits when the root sandbox is prepared early
• fall back to the existing RunWorkload path when an ateom runtime does not implement the new RPCs

Synchronization

RunWorkload remains the barrier: atelet calls it only after both the prepared sandbox and every application OCI bundle are ready. If either parallel leg fails, atelet discards the prepared sandbox with a detached, bounded cleanup context.

Testing

• make verify
• real gVisor lifecycle with runsc in throwaway user, mount, and network namespaces
  • starts the pause/Sentry in PrepareSandbox
  • verifies the application is absent before RunWorkload
  • retries cleanup after a deliberately partial discard failure
  • starts the application as a subcontainer in the prepared sandbox
• compatibility test for runtimes returning Unimplemented
• Appropriate changes to documentation are included in the PR (internal API comments; no user-facing configuration change)

[Benjamin Elder (BenTheElder)]

#968 (comment)

[Du Bin (dubin555)]

Thanks — agreed. The issue's statement that "nothing about the sandbox itself depends on the actor image or checkpoint" is too broad for microVM: its boot/restore requires the application rootfs to be staged for virtiofsd/find-paths.

This PR intentionally implements only the gVisor cold-Run optimization. microVM returns Unimplemented for PrepareSandbox; atelet treats that as "optional fast path unsupported", waits for the runtime assets and all OCI bundles, and then invokes the unchanged microVM RunWorkload, which stages the rootfs and performs the complete VM boot.

All Restore paths, including FULL and DATA_ON_GOLDEN, are unchanged. They still wait for checkpoint download and OCI preparation before calling RestoreWorkload.

Therefore this PR is related to #968, but does not implement early microVM boot or close the microVM/Restore portions of the issue.

[Benjamin Elder (BenTheElder)]

We're doing uVM-first currently, so I'm not super keen to see new complications that are only implemented for gvisor. Earlier in the project we only had gvisor but we've closed the feature gap (not performance yet, in progress).

Can we please look at how this would make sense for uVM before changing the APIs? Thank you.