No SQLite locking for concurrent arbiterx map processes

[NeelPrime]

Summary

If two arbiterx map processes run simultaneously against the same project, they will both write to the same SQLite database without coordination, causing sqlite3.OperationalError: database is locked or data corruption.

Reproduction

# Terminal 1
arbiterx map &

# Terminal 2 (immediately)
arbiterx map
# → sqlite3.OperationalError: database is locked

Root Cause

MapStore opens a SQLite connection without any locking strategy. There is no file lock, no WAL mode, and no retry logic for busy databases.

Expected Behavior

• Either: acquire a file lock before writing (only one arbiterx map at a time)
• Or: use SQLite WAL mode + busy_timeout to allow concurrent reads with serialized writes
• Or: detect an existing map process and exit with a helpful message

Suggested Fix

Option A (simplest): Add conn.execute("PRAGMA journal_mode=WAL") and conn.execute("PRAGMA busy_timeout=5000") on connection open.

Option B (safest): Use a file lock (e.g., .arbiterx/map.lock) to prevent concurrent map operations.

Impact

Low — only affects users who accidentally run arbiterx map twice simultaneously. Single-process usage is unaffected.