Resume prepared Lab benches after retryable admission failures

[chubes4]

Problem

A runner-pinned fixture-matrix bench completed all expensive controller preparation before failing at Lab admission:

1. Rig install.
2. Rig sync.
3. Static Site Importer workspace snapshot/upload.
4. Blocks Engine fixture workspace snapshot/upload.
5. Unique PHP transformer package snapshot/upload.
6. Runner command construction and path translation.

Admission then failed with a stale lease or retryable /admissions transport error. Retrying the same command repeated the entire preparation sequence with new workspace identities instead of resuming the already prepared handoff.

The failed attempt also reported reaping the run-scoped SSI workspace even though the user-facing bench had not started successfully.

Context: browser verification for Automattic/blocks-engine#659.

Expected behavior

Homeboy persists a durable prepared-handoff checkpoint before admission. A retryable pre-acceptance failure reuses verified snapshots and resumes from admission, while cleanup runs only after terminal completion or explicit cancellation.

Acceptance criteria

• Prepared component/package snapshots have content-addressed reusable identities.
• Retryable admission failures retain those snapshots for a bounded recovery window.
• The command automatically retries admission against the current healthy daemon.
• A manual retry can resume by run/checkpoint ID without repeating rig install, sync, and uploads.
• Cleanup policy distinguishes successful workload completion from pre-acceptance failure.
• Output states exactly which preparation stages were reused.

AI assistance

• AI assistance: Yes
• Tool: OpenCode with OpenAI GPT-5.6 Sol
• Used for: Comparing repeated handoff logs and identifying duplicated preparation and premature cleanup.

[chubes4]

Additional reproduction from the same Blocks Engine PR #659 verification flow:

• Runner job: afecb0a5-5cb1-44f9-aebb-c5764c04cf83
• Persisted run: runner-exec-bench-static-site-importer-homeboy-lab-afecb0a5-5cb1-44f9-aebb-c5764c04cf83
• Primary and path-setting snapshots both materialized successfully.
• The accepted remote command failed before workload execution during scenario validation.
• The controller then reported: reaped run-scoped workspace ... (delete-on-success cleanup policy) despite terminal status failed.

This extends the cleanup problem beyond admission transport failure: a pre-workload remote validation failure also destroys the prepared diagnostic workspace while labeling the action as success-only cleanup. Recovery cannot inspect or resume that exact environment and must rematerialize both snapshots.

[chubes4]

Shipped — changelog: "preserve the prepared workspace on retryable admission failure ([#9469])" (docs/changelog.md:847), with in-tree references at lab/offload/inner.rs:2019 ("retry to repeat the entire prep sequence with new identities (#9469)") and workspace/tests/reap.rs:303.

---

Closed as part of a full open-issue triage sweep (2026-07-29), verified against origin/main @ 7dd04b69. If this premise still reproduces, reopen with fresh evidence — a partial or regressed fix is exactly the case this sweep can get wrong.