Recover stale WordPress archive cache locks after interrupted runs

[chubes4]

Problem

Interrupted concurrent recipe-run executions can leave the shared WordPress archive cache lock unavailable. Subsequent independent runs wait through both the primary and fixture-recovery attempts, then fail before WordPress starts.

Observed while validating Automattic/blocks-engine#663 after a controller timeout left duplicate retained executions:

PlaygroundStartupAssetError
code: wp-codebox-playground-startup-asset-unavailable
phase: preview:loading-wordpress
asset: wordpress-archive-cache-lock
sourceUrl: /home/chubes/.wordpress-playground/7.0.2.zip.lock
message: Timed out waiting for WordPress archive cache lock

The clean follow-up used a unique output directory and no concurrent fixture process, but both the normal batch and automatic recovery batch timed out on the same lock. It produced no browser summary.

Expected

The startup asset resolver should distinguish an actively owned lock from a stale lock left by an interrupted/dead process and recover the stale case safely. Parallel healthy owners must remain serialized.

Evidence

• Runner: homeboy-lab
• WP Codebox: 0.12.29
• Runtime: runtime-mruz2z83-7kaoki
• Run: run_cb9ccecf6dfb452fbbb3e6ba3239329b
• Retained workspace: /home/chubes/Developer/_lab_workspaces/blocks-engine-fix-project-image-selectors-2e71f61c0eed-960d5578-79d0-442e-b941-b66e2d9f4dbe-1784657092502579000
• Recovery output: artifacts-fisiostetic-image-wrapper-v11/ssi-matrix/wp-codebox-output-batch-001-recovery-fisiostetic.json

Acceptance

1. Kill/interupt a process while it owns the WordPress archive cache lock.
2. Start a second recipe-run for the same WordPress version.
3. The second run safely recovers the stale lock and starts WordPress.
4. A genuinely active concurrent owner remains protected from lock stealing.

AI disclosure

Diagnosed with openai/gpt-5.6-sol.

[chubes4]

Correction after inspecting the exact Lab installation: /home/chubes/.cache/homeboy/wp-codebox/source is at 795028fc, before merged cache-lease recovery PR #1936 (7befb071). The retained lock is an expired v1 lease (expiresAt: 1970-01-01T00:00:00.000Z), which current main already removes in cacheLockIsActive(). This report is therefore a Lab WP Codebox freshness/distribution problem rather than a missing recovery primitive in current WP Codebox. The Lab installation must be upgraded before repeating the browser proof; no lock was manually removed.

[chubes4]

Operator-approved Lab upgrade completed: /home/chubes/.cache/homeboy/wp-codebox/source fast-forwarded from 795028fc to a9edf319, dependencies reinstalled, and CLI rebuilt. The next matrix run automatically reclaimed the expired 7.0.2.zip.lock, started WordPress, and produced complete browser evidence. This confirms current main already resolves the reported behavior; the incident was stale runner distribution.

[chubes4]

Confirmed resolved on the Extra Chill runner after refreshing Homeboy's managed WP Codebox cache from v0.12.14 to v0.13.2. The same Homeboy test path now passes archive-lock startup and proceeds to runtime-service provisioning; current WP Codebox already contains the stale-lease recovery.