v1.16.1

v1.16.1 HOTFIX — block-finds Lock → RLock (deadlock fix)

v1.16.0 shipped with a Python `threading.Lock()` for _block_finds_lock.
Lock is NOT reentrant — same thread cannot acquire it twice. But every
public block-finds helper (_pending, _recent, _record, _ack) follows
the pattern:

    with _block_finds_lock:
        finds = _block_finds_load()  # ALSO tries to acquire lock → deadlock
        ...

The first request to /api/block-finds deadlocks forever, leaving the
lock permanently held. Subsequent requests pile up unanswered.

Symptom: in the browser, the dashboard polls /api/block-finds every
5s. Hung requests exhaust the browser's per-host connection pool
(typically 6), so unrelated calls (/api/license/status, /api/alerts/
config) appear stuck on "Loading" even though they individually
respond in milliseconds. Nathan caught it within 60 minutes of the
v1.16.0 release going live to all desktop users.

Fix: one character — Lock → RLock. RLock is reentrant; the same
thread can acquire it multiple times (incremented internal counter,
released on matched __exit__). Other architecture stays the same.

Smoke test added: call _block_finds_pending() and _record() on a
fresh cache with a tmp path; with v1.16.0 these would have hung
forever, with v1.16.1 they return immediately.