Recover orphaned Playground WordPress archive locks

[chubes4]

Problem

withPlaygroundArchiveCacheLock() represents ownership only as <version>.zip.lock/. If a process exits before its finally, that directory remains forever. Future runs cannot distinguish it from a live lock, wait 120 seconds, and fail with wordpress-archive-cache-lock.

Observed during the Intelligence v0.34.3 release with an unowned lock from 2026-07-21. Two retries failed before WordPress boot.

Expected

Archive cache locks carry owner identity, dead owners are reclaimed atomically, legacy ownerless locks are reclaimed after a conservative stale threshold, and an owner only removes its own lock.

Reproduction

1. Create ~/.wordpress-playground/7.0.2.zip.lock/ with no owner process.
2. Run a WP Codebox recipe targeting WordPress 7.0.2.
3. Startup waits 120 seconds and fails instead of recovering the orphan.

[chubes4]

Resolved as an installed-runtime mismatch rather than a missing main-branch fix. Owner-aware stale-lock reclamation shipped in #1930 and v0.13.0. The active local runtime was v0.12.22. After switching to v0.13.0, the exact 16-hour legacy lock at ~/.wordpress-playground/7.0.2.zip.lock was reclaimed in 10 ms and WordPress startup proceeded. Closing as already fixed by #1930.