fix(graph): guard store_file_batch against open transactions (#489)

[Devilthelegend]

store_file_nodes_edges already rolled back any uncommitted transaction before issuing BEGIN IMMEDIATE, but store_file_batch did not. When a caller had an explicit BEGIN open, store_file_batch raised sqlite3.OperationalError: cannot start a transaction within a transaction.

Extract a small _begin_immediate() helper and use it from both call sites so the guard stays consistent. Adds a regression test that exercises both methods with an explicit BEGIN already active.

Fixes #489

[tirth8205]

Thanks @Devilthelegend — this is a clean, well-scoped fix and I've merged it. I applied it locally on top of main: test_graph.py, test_transactions.py, test_incremental.py, and test_tools.py all pass (165 tests), your regression test fails without the fix and passes with it, and ruff/mypy are clean. Extracting _begin_immediate() instead of duplicating the guard was the right call — it gives us one place to change when we harden this further.

Two notes for the record, neither blocking: store_file_batch currently has no in-package callers, so this is API-consistency hardening rather than a hot-path fix; and the guard's rollback semantics mean a leaked transaction's writes are discarded rather than committed — that matches the existing convention in test_transactions.py, but I'm filing a follow-up to serialize writers with a lock so a concurrent thread's in-flight transaction can never be rolled back from under it. Appreciate the regression test covering both call sites.