Handle nested SQLite transactions during builds

[GrimoireScribe]

Summary

• make store_file_nodes_edges() safe when the SQLite connection is already inside a transaction
• use a savepoint for nested writes instead of always issuing BEGIN IMMEDIATE
• add a regression test covering file-store writes during an existing transaction

Why

On Windows, rebuilding the graph could fail with:

ext sqlite3.OperationalError: cannot start a transaction within a transaction

This happens when store_file_nodes_edges() is called while the connection is already in a transaction. Using a savepoint preserves the atomic per-file replace behavior without assuming top-level transaction ownership.

Verification

• python -m ruff check code_review_graph/graph.py tests/test_graph.py
• local CLI build completed successfully against a real repo after the change

[tirth8205]

Closing in favor of #205 which provides a more complete fix.

Your savepoint approach is technically valid and clever — it preserves atomic per-file replace semantics when the connection is already in a transaction. However, it is a symptom-level fix: it works around the implicit transaction left open by remove_file_data() without removing the underlying source of that transaction.

PR #205 goes further in three ways:

1. Root cause fix: sets isolation_level=None on all three sqlite3.connect() calls (graph.py, registry.py, embeddings.py), disabling implicit transactions project-wide so the leaking transaction can never occur in the first place.
2. Completeness: also wraps store_flows(), store_communities(), and the three _compute_summaries blocks in explicit transactions for atomicity — sites that your PR leaves untouched.
3. Incremental path: adds store.commit() after the stale-file purge loop in full_build() and the deleted-file loop in incremental_update(), so the fix is also applied at the call-site layer.

Additionally, the nosec B608 annotation on the f-string SAVEPOINT names is a code smell — even though the savepoint name is a hardcoded literal, the annotation suggests it needs suppression. The savepoint name could be passed as an identifier via the sqlite3 API instead (or simply avoided, as #205 does). Thank you for the contribution!