Use heartbeat-based lock liveness instead of PID + process start time #862

Proposal

Replace the PID + process start time liveness check in lock recovery with a heartbeat: the lock holder periodically refreshes the lock file's timestamp (e.g. mtime), and a lock is considered stale once it has gone longer than the deadline without a refresh. No process query is needed.

Motivation

PID + start time exists only to rule out PID reuse, but it depends on per-platform process queries that keep proving fragile:

• On Windows, the WMI query via cscript emits UTF-16 output, which was silently misparsed (test: close the five highest-value gaps from the test audit #857).
• The PowerShell alternative has slow cold starts that can consume most of the 5s recovery deadline, one source of the flaky lock-recovery test in Flaky CI tests: session-history E2E anchor, Windows git-info refresh, Windows setup-config lock timeout #829.

A heartbeat is platform-independent, simple to reason about, and easy to test deterministically (control the clock/mtime).

Open questions

• Refresh interval vs. stale deadline (e.g. refresh every 1s, stale after 5s).
• Behaviour for long blocking operations in the holder (refresh from a timer/thread).
• Migration: handling lock files written by older versions.

Refs #829, #857.