fix(palace): reap orphaned per-source-file mine locks

[fxinfo24]

Problem

_cleanup_mine_lock_file reclaims a lock correctly on the happy path — but only for the specific lock a mine_lock context manager just released. A process that dies before reaching its own finally block (SIGKILL, force-quit, host crash) never runs that cleanup, and nothing else in the codebase later revisits the lock file.

Found in the wild: one long-lived installation had 5,636 stale lock files in ~/.mempalace/locks/, the oldest several months old, none held by any live process (confirmed via lsof before manual cleanup).

I checked this wasn't already covered before writing a fix:

• mine: silent exit when concurrent writer holds chroma lock; should detect live mcp_server and back off with clear error #1264 (lock-holder-diagnostics, merged) — identifies who holds a live lock and fails loudly on contention. Doesn't reclaim orphans.
• MCP server SIGSEGV on tool_diary_write in 3.3.4 — Connection closed; server unrecoverable in-session #1299 (mcp_server missing embedding_function) — different code path (MCP server's own collection-reopen), unrelated.
• The 2026-07-10 outage postmortem comment in mcp_server.py's stdio loop — covers graceful client disconnection (stdin EOF/error → clean shutdown → the process's own lock-release runs). Doesn't cover abrupt process death, where that shutdown code never gets to run at all.

None of the three address orphan reclamation for a process that's simply gone.

Fix

reap_stale_mine_locks() reuses _cleanup_mine_lock_file itself for the actual removal — same nonblocking-flock-reacquire safety mechanism, same Windows/POSIX handling already tested in this file, no duplicated locking logic. A lock is only ever removed after this process re-acquires it via the existing flock, so anything genuinely held by a live process is left untouched regardless of how old it looks by mtime — age is a courtesy throttle (avoids racing a lock that was just released and may still be mid-rendezvous with a waiter on the same pathname), not the safety mechanism.

Wired into mine_lock() via a throttled opportunistic call (_maybe_reap_stale_mine_locks, at most once per 15 minutes) rather than a new background thread, scheduled task, or CLI surface — it piggybacks on the natural cadence of mining rather than adding new infrastructure.

mine_palace_*.lock (the newer per-palace lock from the #974/#965 fan-out fix) is explicitly skipped — separate lifecycle, separate holder-identity tracking, not affected by this failure mode.

Testing

6 new cases in test_palace_locks.py:

• removes a genuinely stale + unheld lock
• leaves a young lock alone regardless of hold state
• core safety property: a lock held by another process (real cross-process test via multiprocessing) is never removed, even when its mtime is backdated past the age threshold
• skips mine_palace_*-prefixed locks
• missing lock dir is a no-op
• the opportunistic throttle itself

Full existing test_palace_locks.py suite (19 tests) passes unchanged. Broader tests/ -k 'palace or mine' run clean — 730 passed, 10 skipped — aside from two pre-existing failures I confirmed are unrelated and present on an unmodified develop checkout before touching anything (test_hnsw_capacity.py SQLite WAL signature caching, test_repair.py FTS5 shadow-table write restriction — both environment/SQLite-build-specific, neither touches locking).

ruff check clean on both modified files.

Compatibility

Purely additive — no existing function signatures changed, no new required config, no new CLI surface. The one behavioral change is that mine_lock() now does a cheap, throttled, best-effort directory scan at most once per 15 minutes; failures in that scan are swallowed (logged at debug level) and never propagate to the caller's actual mine operation.

[igorls]

Wave 2 for 3.7.0: LGTM after review. Merging into develop for the release train.