fix(lock): harden FileLock ownership semantics and lock diagnostics

[thismilktea]

Tighten FileLock ownership semantics and improve lock conflict diagnostics.

The old lock model stored only a PID and treated sufficiently old lock files as stale. That was a pragmatic recovery
path, but it seems less well suited to CodeGraph’s current usage patterns, where overlapping writer candidates (index,
watcher-driven sync, MCP, git hooks) are possible and indexing/sync duration can vary with repo size and workload.

This PR updates FileLock to:

• store structured lock metadata (pid, token, createdAt, hostname)
• use token-based ownership checks on release()
• treat locks as stale only when the owner appears to be dead or the lock file is unreadable
• preserve richer lock-holder context in indexAll() / indexFiles() errors
• keep sync()’s existing zero-result sentinel behavior unchanged

Tests

Extended tests/security.test.ts to cover:

• JSON lock metadata
• legacy PID-only lock compatibility
• dead/corrupt lock cleanup
• token mismatch on release()
• richer lock conflict propagation

Also re-ran:

• tests/concurrent-locking.test.ts

Tradeoff

This does give up one aggressive recovery path: a lock held by a still-alive but effectively wedged process may now
persist longer. On balance, that seems preferable here, since it avoids treating legitimate long-running writes as
stale in multi-writer scenarios.