Sandbox creation fails with generic error when template files are in archived storage class

Bug Description

When S3/S3-compatible object storage lifecycle rules transition template build files to archived storage classes (e.g. GLACIER, ARCHIVE_FR, COLD_ARCHIVE), attempting to create a sandbox from those templates fails with a generic Internal gRPC error instead of a clear, actionable message.

Root Cause

The AWS storage provider in packages/shared/pkg/storage/storage_aws.go only handles NoSuchKey errors from GetObject/HeadObject calls, mapping them to ErrObjectNotExist. However, when objects are archived, S3-compatible backends return an InvalidObjectState error instead, which falls through to the generic error path.

The orchestrator (packages/orchestrator/pkg/server/sandboxes.go) only checks for ErrObjectNotExist to return a FailedPrecondition status. The unhandled InvalidObjectState results in a codes.Internal error with the message "failed to create sandbox", giving users no indication that the issue is related to archived storage.

Expected Behavior

When sandbox files are archived, the system should return a clear FailedPrecondition error like:
sandbox files for '' are archived and not directly accessible, please rebuild the template

Affected Code Paths

• awsObject.WriteTo() - blob reads
• awsObject.OpenRangeReader() - range reads for block devices
• awsObject.Size() - object metadata queries
• Server.Create() - sandbox creation error handling

Environment

This affects deployments using S3-compatible storage backends (e.g. Volcengine TOS, AWS S3, MinIO) with lifecycle rules that transition objects to archived storage classes.

Read packages/shared/pkg/storage/storage_aws.go and trace awsObject.WriteTo(), OpenRangeReader(), and Size(), then follow the error handling in packages/orchestrator/pkg/server/sandboxes.go Server.Create(). Verify archived-object failures produce the stated FailedPrecondition message instead of the generic Internal error across the affected code paths.