fix(graph): make concerns/reflection writes actually atomic

[pradeepmouli]

Fixes #67 (Bug 2 of 2). Depends on #68 (this branch is stacked on it) -- the diff will shrink to just this PR's changes once #68 merges.

What

write_concerns and reflection's equivalent write_resolves_to issued BEGIN TRANSACTION/COMMIT through raw_query, believing that made their delete-then-recreate loop atomic. It never did:

• KuzuBackend::raw_query opens a fresh connection per call, so transaction-control statements issued through it can never span more than the one statement they're attached to.
• Neo4jBackend::raw_query no-ops the same statements for a different reason (Neo4j transactions are driver-level, not Cypher).

Both backends' raw_query already document this and deliberately no-op those statements rather than error -- but neither caller knew that, so every individual DETACH DELETE/CREATE in the loop auto-committed independently. A crash mid-loop today already means the old concerns/RESOLVES_TO edges are gone and only some of the new ones landed -- live data-loss exposure, not hypothetical.

Fix

• GraphStore::transaction<T>(&self, f: impl FnOnce(&Connection) -> Result<T>) -> Result<T> -- opens one connection, issues a real BEGIN TRANSACTION, runs f against it, commits on Ok, rolls back on Err.
• Two new GraphBackend trait methods, replace_concerns and replace_resolves_to, following the same "backend owns the transaction" design as the existing write_calls_service_edges. New Concern/ResolvesToEdge structs live in backend.rs (mirroring CallsServiceEdge) rather than reusing the analysis-pass types (ConcernMatch/ReflectionSite), keeping those out of the storage layer.
• KuzuBackend implements both via the new store.transaction().
• Neo4jBackend implements both as a single chained Cypher statement (delete + UNWIND-based recreate) -- matches write_calls_service_edges's existing precedent of "one auto-committed statement, no driver-level transaction needed" for that backend.
• write_calls_service_edges itself also migrates onto store.transaction(), removing its hand-rolled BEGIN/loop/COMMIT/ROLLBACK boilerplate (same behavior, no longer duplicated).
• The free write_concerns/write_resolves_to functions in concerns/mod.rs/reflection/mod.rs are deleted; their one call site each now builds the new backend-layer structs and calls the trait method directly.

Testing

New file tests/concerns_reflection_atomic_writes.rs, 7 tests:

• replace_concerns_rolls_back_atomically_on_mid_batch_failure -- forces a mid-batch failure (two Concerns with the same id, colliding on Kùzu's primary key) and asserts a pre-existing concern survives untouched, proving the whole batch rolls back together. This fails against the pre-fix code (the old per-row let _ = swallowed the error entirely and always returned Ok, let alone rolled back).
• Direct commit/rollback tests for GraphStore::transaction().
• Basic correctness tests for both new trait methods (creates edges, replaces rather than accumulates, empty-input still clears old data).

All pass under both default and --features remote (neo4j). cargo fmt --all -- --check and cargo clippy --all-targets -- -D warnings both clean under both feature sets. Pre-commit hook's perf suite (write_lock_perf, groups_watch_perf, index_perf) all pass.

Note: the Neo4j-side Cypher hasn't been run against a live instance -- matches this codebase's existing precedent (the reference write_calls_service_edges Neo4j test is #[ignore]d for the same reason).