fix(palace): pair the mine_palace_lock holder-set update with its release (#1970)

[mvalentsev]

Fixes #1970.

What does this PR do?

mine_palace_lock() recorded the process-wide hold with _mark_held(palace_key) before the try: whose finally: runs _mark_released(). An async exception (a KeyboardInterrupt/SIGINT, or one injected into a thread) landing in the gap after _mark_held() and before the try: skips _mark_released(), so palace_key is left in the _palace_lock_keys set. The outer finally: still frees the flock, so the in-memory holder set outlives the OS lock: _held_by_this_process() then reports a hold the flock no longer backs, the next re-entrant acquire in this process passes through and writes without the flock, and another process is free to acquire it at the same time. That is two writers into one palace, the HNSW-corruption race the lock is there to stop.

The fix moves _mark_held() to the first line inside the try:, so it pairs with _mark_released() on every exit. _mark_released() is a set.discard, so releasing a key that was never added is a no-op, and the normal acquire/release path is unchanged.

How to test

tests/test_palace_locks.py::test_holder_set_not_orphaned_by_interrupt_after_mark_held runs the real _mark_held, then raises in the window as a signal would, and asserts the holder set is unchanged afterwards. It fails on the current code (the key is stranded) and passes with the fix.

uv run pytest tests/test_palace_locks.py tests/test_chroma_collection_lock.py

Checklist

• Tests pass (python -m pytest tests/ -v)
• No hardcoded paths
• Linter passes (ruff check .)

[mvalentsev]

The red lint check isn't from this PR. ruff format --check . flags tests/test_mcp_server.py, which went in unformatted with #1960 and isn't touched here. #1965 fixes that, so this should go green once it lands.