MCP cgis_ingest: always-incremental with no full-rebuild option + summary reports per-batch delta, not whole-graph totals

[zaebee]

Summary

Two related UX problems in the MCP cgis_ingest tool (src/cgis/api/mcp_server.py:49), surfaced while dogfooding during #116.

1. Always incremental, no way to force a full rebuild

cgis_ingest always calls pipeline.run(project_path, store=store) with a store, so it always runs in incremental mode (pipeline.py:59 — store provided ⇒ incremental). The CLI has an explicit --incremental flag (default off ⇒ full rebuild); the MCP tool has neither the flag nor any way to force a clean full re-scan. Today the only way to force a full rebuild via MCP is to delete the .db out of band.

2. Summary counts are the per-run working set, not the graph total

The returned Nodes / Resolved edges reflect what pipeline.run returns for this run, which in incremental mode is the changed-file working set — not the whole graph. A no-op re-ingest therefore looks like the graph shrank.

Reproduced (this session):

ingest src/ (fresh db)      → reported  959 nodes / 2783 edges   | DB actually holds 959 nodes
re-ingest src/ (no changes) → reported  416 nodes / 0    edges   | DB still holds   959 nodes

0 resolved edges on a healthy graph is especially misleading — it reads as "no edges resolved" when nothing simply changed.

Proposal

• Add a full_rebuild: bool = False param to cgis_ingest (when true, ingest without a store / clear first → full re-scan), mirroring CLI semantics.
• After persisting, report whole-graph totals (e.g. store.get_node_count() / edge stats) instead of the per-batch return, or report both ("changed this run: X; graph total: Y").

Why it matters

Agents/humans use the returned counts as a sanity signal. A re-ingest that prints a smaller number (or 0 edges) reads as data loss and erodes trust in the graph, when the DB is in fact correct.