Version tags on indexed nodes + diff_versions tool for cross-version change detection

[isc-tdyar]

Feature proposal: stamp a version tag on every node at index time, then compare two indexed versions of the same project to find added/removed nodes.

Motivation

When indexing multiple releases of a large codebase (e.g. version 28.0 and 30.0 of a product with 1,000+ classes), it's useful to query what changed between versions without diffing source files directly. The graph representation makes cross-version analysis composable with the rest of the Cypher query surface (DEFINES_METHOD, CALLS, IMPORTS, etc.).

Proposed API

cbm_pipeline_set_version(cbm_pipeline_t *p, const char *version_tag)

Sets a version label on a pipeline instance. When set, the tag is written as a "version" property on every node. Also bypasses the incremental-index path so versioned indexing always does a full pass — the graph accumulates both versions side-by-side rather than replacing the previous snapshot.

index_repository tool: new version parameter

{ "repo_path": "/repos/myproject-28.0", "version": "28.0" }

When omitted, a version-like segment (digits and dots) is auto-derived from the repo path.

diff_versions MCP tool

{
  "project":      "myproject",
  "from_version": "28.0",
  "to_version":   "30.0",
  "label":        "Class"
}

Returns {"added": [...], "removed": [...], "from_version": "28.0", "to_version": "30.0"}. Default label Class, limit 500 per side.

Implementation scope

• pipeline.h — new public cbm_pipeline_set_version()
• pipeline_internal.h — version_tag field on ctx
• pipeline.c — setter, free, skip-incremental guard, ctx wiring
• pass_definitions.c / pass_parallel.c — version property on all nodes; Storage nodes with structured docstring have fields merged inline as raw JSON
• mcp.c — cbm_derive_version_from_path() helper, version param on index_repository, diff_versions handler

Questions before PR

1. Is there appetite for this feature? It's general-purpose (not IRIS-specific) but the primary motivation is multi-version IRIS codebase analysis.
2. Any preference on how versioned graphs are stored — single DB with version property on nodes (proposed), or separate DBs per version?
3. The diff_versions tool only compares node existence (added/removed by name). Should it also surface structural changes (e.g. method count delta, signature changes)?

[DeusData]

Thanks for the detailed proposal. This is tracked as a 0.9.2-rc backlog enhancement. The design needs explicit graph identity across versions, storage-growth bounds, incremental-index semantics, cleanup policy, and compatibility for clients that do not supply a version tag before adding a new MCP tool.