fix(mcp): attribute post-publish failures to artifact export (#1665)

[umi008]

What does this PR do?

With --persistence true on a read-only repository, index_repository reported status: "error" with the hint "Pipeline failed. Check repo_path exists and contains source files" — blaming the repository for a failure that is actually the post-publish team-sharing artifact export (.codebase-memory/ cannot be written inside a read-only checkout). The graph database itself published fine.

The pipeline now snapshots the artifact export error of the run it just executed (a per-pipeline buffer, not the process-global export error which can describe a previous run). index_repository consults that snapshot on failure and names the real cause: the artifact export, the error detail, and the remedies (writable checkout or --persistence false). Every other failure path keeps the existing hint byte-for-byte.

The fail-hard semantics are unchanged: a failed persistence export still makes the run fail, which is the in-tree documented decision (export_after_publish, "intentionally fails the run"). This change only makes an already-failing run report the truth — the issue-1466-era misleading repo_path hint is what hid the cause.

Verified with a reproduce-first pipeline test: an artifact directory blocked (.codebase-memory as a file), fixture indexed, asserts rc != 0, cbm_pipeline_export_error() non-empty and naming the artifact phase, the DB still published, and a clean re-run leaving the snapshot empty.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thank you for tracing the misleading error to the post-publish artifact phase and for preserving the existing fail-hard contract. I checked current main: artifact export logs its own phase error, but the MCP failure path still returns the generic “Pipeline failed. Check repo_path” hint. That confirms the attribution problem.

Before code review, please remove the 135 lines under the five new openspec/ files. Current main has no openspec/ tree, and CONTRIBUTING.md requires prior approval for project configuration. The focused mcp.c, pipeline, header, and regression-test changes can remain together as the single bug fix. I have labeled this as a normal-priority UX bug. Splitting enables review but does not pre-decide the merge outcome. Thank you for making the existing failure report the actual cause.