fix(setup): recover locks while writers wait

[outlier27-cell]

Problem

A setup writer waiting for my-pi-setup.json.lock only wakes on a lock-file event or at the 5-second deadline. If the lock owner dies without removing the lock, the file never changes, so the waiter times out even though the existing stale-lock recovery could reclaim it.

This is not the config diagnostics or apply-failure rollback tracked by #498 and implemented in #557. #557 still checks the lock only at the deadline. No open PR covers this waiting-writer-after-owner-death sequence. There is no existing Issue for this exact timing.

Value

A Pi process killed while holding the setup lock no longer blocks the next configuration write for the full timeout. The next writer can recover inside the existing 5-second budget instead of failing a save that is already safe to retry.

Approach

Wake the waiter every 500ms, and at the deadline, then retry the existing fail-closed recoverStaleSetupConfigLock path. Lock ownership rules are unchanged: a live owner is never stolen, and an owner whose PID identity is unknown is not reclaimed. The periodic wake only gives the existing recovery another chance to run.

Validation

• bun run check passed on d448dad: config contract, docs contract, discipline ledger, web build, Biome format, Biome lint, and tsc --noEmit.
• node --test --experimental-strip-types tests/extensions/shared/setup-config.test.ts: 21/21 passed, including the new cross-process regression where writer B is already waiting when owner A dies and B recovers within the original deadline.
• bun run test did not complete. It stopped in tests/extensions/post-edit/lifecycle.test.ts: seven real-Pi cases timed out at 15 seconds and one assertion failed. The same file fails the same way on unmodified main at 6132d99, so this is a baseline failure, not a regression from this change. Those tests were not modified.

Impact

• User-visible behavior: a setup save waiting on a dead owner's lock can succeed within the existing timeout instead of failing.
• Model-visible context/tools: none.
• Runtime/lifecycle: the lock waiter wakes every 500ms and reuses stale-lock recovery. Ownership and fail-closed rules are unchanged.
• Persisted config/data: no schema or format change.
• Compatibility or risk: does not close setup: 配置诊断与 fail-closed 回滚，不新增第二条配置入口 #498 and does not conflict in intent with fix(setup): diagnose invalid config and roll back failed applies #557. Recovery still refuses to take a lock when process identity is uncertain.

[tt-a1i]

复审提交 d448dad390bea4daaab8424fd8b09dd823f23655。

未发现阻断问题。等待锁时每 500ms 重新进入既有的 fail-closed 恢复判断，没有放宽活进程、未知 PID 身份或恢复 claim 的所有权规则；新增跨进程用例覆盖了“等待者已经挂起后持锁进程死亡”的原始竞态。当前 Node、Web E2E 和原生 Windows 检查均通过。

验证边界：本结论针对锁等待和恢复路径；不把 PR 描述中在 main 也可复现的 post-edit 全量测试失败归因于本改动。