Summary

Fixes #650 — On Windows, RocksDB LOCK files persist after a process crash (Windows doesn't always release file handles immediately after process termination). This blocks subsequent PersistStore opens with:

IO error: .../LOCK: The process cannot access the file because it is being used by another process.

This PR adds a stale LOCK file cleaner that runs during OpenVikingService.initialize(), after the PID advisory lock is acquired and before storage is opened.

How it works

• Scans for RocksDB LOCK files under the data directory using generalized glob patterns (**/store/LOCK and **/LOCK to cover all PersistStore paths)
• Attempts os.remove() on each LOCK file:
  • PermissionError → file is held by a live process → skip it (safe)
  • Remove succeeds → file was stale from a dead process → cleaned up, PersistStore will recreate it
• No-op on POSIX — flock() handles cleanup natively on Linux/macOS
• Deduplicates across overlapping glob patterns to avoid double-counting

Placement rationale

The cleanup runs in OpenVikingService.initialize() right after acquire_data_dir_lock() (the PID advisory lock from #473). This is the ideal location because:

1. The PID lock ensures we're the only live process starting up
2. Any remaining RocksDB LOCK files at this point are guaranteed stale
3. Cleaning before init_context_collection() prevents the PersistStore open failure

Relationship to #790

PR #790 fixes the PID lock staleness (_is_pid_alive() raising OSError on Windows). This PR fixes the RocksDB LOCK staleness — a separate file created by the native storage engine. Both issues manifest on Windows after crashes but are independent fixes.

Additional context

We discovered this running OpenViking with the Claude Code plugin bridge on Windows 11 across multiple concurrent sessions. The debug log shows the failure pattern clearly:

vikingdb - ERROR - Failed to open data db: IO error: ...\store/LOCK: The process cannot access the file because it is being used by another process.

We have additional findings around live LOCK contention (retry with exponential backoff) and orphan session recovery that we documented in issue #650. Those are better suited for follow-up PRs as they involve more architectural decisions.

Changes

Test plan

• Unit tests cover: standard layout, multiple collections, empty dir, nonexistent dir, POSIX no-op, deduplication
• Tests use pytest.mark.skipif to run platform-appropriate assertions
• Verified in production on Windows 11 with concurrent Claude Code sessions (stale LOCK cleanup resolves the startup failure)

Disclosure: This PR was co-authored by Claude Code (Anthropic's AI coding agent) on behalf of @REMvisual, who directed the investigation, validated the fix in production, and reviewed the code.