fix(sandbox): let a Live sandbox register through a setup package and link from a Worker (ALIEN-1236)

[ItamarZand88]

Summary

A Sandbox added as Live failed when its Terraform or CloudFormation setup registered, because initial setup refused the sandbox record the setup package hands over. This PR leaves that record to the sandbox's runtime controller, and lets a Worker link a Live sandbox.

Step-by-step flow when a setup package registers a stack with a Live sandbox:

1. The package creates the sandbox's build role and registers the sandbox at the start of its create flow.
2. Initial setup checks the registered records. This is where the Live sandbox was refused as "unexpected"; it is now left for its runtime controller.
3. In Provisioning, the controller builds the image, and a Worker linked to the sandbox gets its binding once the sandbox is Running.

This PR changes "a Live sandbox cannot be installed through a setup package" to "it installs, and a Worker can use it".

What was broken

Initial setup runs only the Frozen resources, and it refused any registered record it does not run. Setup always renders a sandbox's build role, so a Live sandbox is registered too, and the install failed with IMPORTED_SETUP_STATE_INVALID after Terraform had already applied. Every sandbox built from a Dockerfile is Live, so none of them could be installed this way. Separately, the preflight still refused a Worker that links a Live sandbox, although the Worker controller waits for the sandbox and reads its binding at runtime.

What I did

• continue_imported accepts a record outside the lifecycle filter only when the stack declares it, its type renders setup scaffolding for its lifecycle (today only a sandbox), and it arrives at the start of its create flow (Provisioning, with controller state). Everything else is refused as before, including a Live sandbox registered as already built.
• The preflight treats a Worker like a Container or Daemon: it may link a Live sandbox. A Build, which setup renders, still may not.
• Woz: nothing to remove; each condition in the guard has a test that fails without it. Limitation accepted: a registered Live sandbox skips the config and dependency comparison Frozen records get, since the importer builds it from the same prepared stack.

Files touched

• crates/alien-infra/src/core/executor.rs: the guard in continue_imported.
• crates/alien-infra/src/core/executor_tests/update_tests.rs: four tests for the guard.
• crates/alien-preflights/src/compile_time/frozen_resource_lifecycle.rs: a Worker may link a Live sandbox; the refusal test now uses a Build.

How I tested

• What I ran: on a local stack against an AWS test account, I installed with Terraform a stack whose Worker links a Live sandbox. Before the fix it failed at registration with Imported setup contains unexpected resource 'test-sandbox' after Terraform applied. With the fix it reached Running, the Worker's sandbox binding carried imageArn and imageVersion, and a request to the Worker created a sandbox session, ran a command, moved a file in and out, and ended the session. Same result with a sandbox built from a Dockerfile. Those runs used the first version of the guard, which accepted any declared record; the final guard accepts the record the AWS importer builds for a Live sandbox, and the unit test builds it with that importer.
• Unit tests: imported_continuation_leaves_a_registered_live_sandbox_to_runtime fails on main with the same error and passes here. Removing the scaffolding check fails imported_continuation_refuses_a_live_resource_setup_does_not_render; removing the Provisioning check fails imported_continuation_refuses_a_live_sandbox_registered_as_built. cargo nextest run -p alien-infra --features all-platforms,test-utils: 853/853. cargo nextest run -p alien-preflights: 409/409.
• Anything I couldn't test: CloudFormation end to end (it registers through the same path). Live sandboxes stay AWS-only, unchanged.

Safe because a record setup does not render, or a Live sandbox registered as already built, is still refused. Proven by the two refusal tests above.

[greptile-apps]

Confidence Score: 5/5

[High risk] Changes resource lifecycle validation and setup state handling.

The PR appears safe to merge; no actionable regression was identified.

Summary

The PR allows initial setup to retain a registered Live sandbox for runtime provisioning and permits a Worker to link to it.

• The import guard still rejects undeclared resources, resources without setup scaffolding, and Live sandbox records that are already Running.
• The updated tests cover the handoff guard and the revised preflight distinction between Workers and setup-rendered consumers.

_{Reviews (1) · Last reviewed commit: "fix(sandbox): let a Live sandbox registe..."}