fix: acquire GIL before AppState write lock to prevent deadlock

[ZhuchkaTriplesix]

Problem

ensure_compiled_snapshot (dispatch.rs), setup_database, and close_database (lib.rs) took the AppState write lock and then called rebuild_snapshot(), which acquires the GIL internally to clone Py<PyAny> handles. These run on tokio worker threads without the GIL already held (async run_rsgi path, or a spawned future), so the lock order there was Rust lock → GIL.

Elsewhere (e.g. handle_rsgi), the order is GIL → Rust lock (GIL held for the whole pymethod call, then state.read()/state.write()).

Two different lock orders on the same pair of locks is a textbook AB-BA deadlock: one thread can hold the Rust write lock while blocked acquiring the GIL, while another thread holds the GIL and is blocked acquiring the Rust lock. Under real concurrency (e.g. no explicit freeze() + any middleware, which skips the sync short-circuit) this hangs the worker.

Fix

Acquire the GIL first in all three call sites, then take the write lock inside that scope — matching the GIL-then-lock order used everywhere else in the hot path. Python::with_gil is reentrant, so this is a no-op cost when GIL is already held (e.g. pymethods).

Testing

cargo build --lib passes. No behavior change to the lock-free read path.

Closes #205

[ZhuchkaTriplesix]

123