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)