feat: Google Cloud Spanner Graph integration - #766

@m-guesnon-pvotal is attempting to deploy a commit to the shashankss1205's projects Team on Vercel.

A member of the Team first needs to authorize it.

Hey @m-guesnon-pvotal Can you please merge the latest changes and then add these on top of them. I re-added some parts of the visualization...

@Shashankss1205 done.
Great job on this btw.
Note that I'm not really convinced by the approach on the "spanner wrapper" but that's the faster I could come up with.

Still in draft, so leaving it as-is — just flagging that it now conflicts with main in 9 places (pyproject.toml, config_manager.py, cli/main.py, core/__init__.py, tool_definitions.py, graph_builder.py, query_handlers.py). The backend registration surface in core/__init__.py in particular has changed shape since March.

No action needed if this is parked. If you do want to pick Spanner Graph support back up, rebasing sooner rather than later will be less painful — and worth noting #1302 is proposing changes to how backends are registered, which would affect this.

Queue sweep — five months open, conflicting with main.

A Spanner Graph backend is a legitimate ask and the work looks serious, so let me give you a real answer rather than a rebase nudge.

The blocker is the parity matrix, not the code. CGC supports four backends today — Kuzu, LadybugDB, FalkorDB, Neo4j — and they're held to a Database Parity Check in CI that indexes tests/fixtures/sample_projects/ on every one and asserts identical node and relationship counts. That check is the only thing keeping the backends from quietly diverging, and it is the single most expensive piece of infrastructure in this repo to keep green; a meaningful fraction of recent releases have been spent chasing backend-specific edge drops. Adding a fifth backend means adding a fifth column, and a managed cloud service is much harder to hold to that standard than an embedded engine — it needs credentials in CI, it costs money per run, and a flaky cloud dependency turns the parity check red on unrelated PRs, which trains everyone to ignore it.

So before a rebase is worth your time, I need to know:

1. How would this be tested in CI? Is there a Spanner Graph emulator that can run in a GitHub Actions job? If yes, this becomes much more tractable and I'd want to see that wired up as part of the PR. If no, the honest answer may be that Spanner lives outside the parity matrix as an explicitly best-effort backend — which I'd consider, but it needs to be stated in the docs so users know what guarantee they're getting.
2. How much of the diff is Spanner-specific versus generic? If some of the 991 lines are improvements to the backend abstraction itself, those can land now, independently, and shrink whatever remains.
3. Who maintains it? A backend nobody uses and nobody can test decays into broken code that looks supported. If you're using this in production and willing to be pinged when it breaks, say so — that materially changes my answer.

Answer those and I'll give you a clear yes or no rather than leaving it to age out. I'd rather tell you no now than have you rebase 991 lines into a maybe.