index_repository name override can silently clobber a different project's index

[phaedrus1992]

Summary

index_repository's name parameter overrides the derived project key, but
nothing checks whether that name is already bound to a different repo
root. Calling index_repository(repo_path: <some-repo>, name: "<existing-project>")
silently deletes and recreates <existing-project>'s index with data from
the wrong repo — no error, no prompt.

Details

cbm_validate_project_name (src/foundation/str_util.c) only checks the
name for path-traversal characters — it doesn't look up whether the name is
already registered to a different repo_path. handle_index_repository
(src/mcp/mcp.c) calls cbm_pipeline_set_project_name(p, name_override),
and the resulting pipeline unlinks and recreates the .db file at
<CBM_CACHE_DIR>/<name>.db (src/pipeline/pipeline.c) regardless of
whether that file already belongs to an unrelated project.

Any MCP client that shares one CBM_CACHE_DIR across multiple projects (a
reasonable, even encouraged, setup for a single cache directory) is exposed:
a name typo, or a client-side auto-fill that guesses the wrong project
name, replaces someone else's index with no confirmation.

Mitigating factor: an index is derived data, so the fix is "re-index the
correct repo" rather than data loss — but a full reindex runs
capture_existing_adr before unlinking, so at least the ADR document itself
survives the collision.

Suggested fix

index_repository should refuse a name override that already resolves to
an existing project whose recorded repo_path differs from the one supplied
in the call — return an error (e.g. "name '' is already bound to
; use --force to override" or similar) instead of silently
overwriting. This keeps the common case (first-time indexing, or re-indexing
the same repo under the same name) unprompted, while catching the
cross-project collision.

Found via

Downstream client integration (llmenv) — see llmenv issue
phaedrus1992/llmenv#1331 for the client-side
analysis that surfaced this.