fix: preserve filesystem lock ownership during recovery

[smiggleworth]

Two commands recovering one stale lock could delete a newly acquired lock and enter the same file/directory transaction concurrently. The guarded file reproducer lets both stale plans succeed. Replace duplicated recursive lock removal with one protocol that prepares a unique owner before publishing a nonempty lock, unlinks only the observed dead owner or this operation's owner, and removes directories only when empty. Preserve ambiguous contents and junctions instead of deleting unrelated paths.

Validation: six minimal regressions fail against immutable pre-fix source. All 401 unit cases and main release checks pass locally, including deterministic stale-reaper races, stale-write rejection, legacy recovery, partial preparation/cleanup failure, exclusive-creation collision, successor ownership during release, denied process probing, six filesystem errors and two actual process-termination cases before lock publication. Existing directory/generator/file crash cases also run with this protocol. Packed TypeScript 6.0.3/7.0.2 checks cover two retained names, nine removed imports and 15 private paths. Publication records, directory swaps and file staging/rollback bodies are byte-identical to the accepted base; the skills-copy barrier follows lock-rename contention with its original behavior assertions. All five packed templates, the minimum peer version, production audit (zero findings), formatting and all 22 unchanged performance gates pass.

Refs #159. No versions, dependencies, workflows, budgets or benchmark fixtures change. This qualifies current cooperating CLI commands and tested termination checkpoints; active older lock protocols and power-loss durability are outside the qualification. Remaining malformed-input/subprocess probes, the frozen 0.5 graph/site and maintainer review still gate release.