fix: create the first persistent artifact on the incremental path

[mvanhorn]

What does this PR do?

Fixes #434: enabling persistence=true did not create the first persistent artifact on the incremental indexing path. dump_and_persist in pipeline_incremental.c only refreshed an artifact that already existed and never created one on first run, so a persistence=true request was silently a no-op until an artifact happened to exist. git ai stats-style consumers saw the index reported as successful with no persistent artifact written.

This threads a new cbm_pipeline_persistence() accessor into the incremental path (mirroring the existing cbm_pipeline_repo_path / cbm_pipeline_project_name accessors) so it exports the first artifact with CBM_ARTIFACT_BEST when persistence is requested and none exists, matching the full pipeline. Existing artifacts keep refreshing with CBM_ARTIFACT_FAST. It covers changed-file, deleted-file, and no-op incremental runs, and it now propagates a failed cbm_artifact_export as a run error instead of reporting a successful index when the artifact could not be written.

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)

[DeusData]

Thanks for covering both changed-file and no-op incremental paths and for propagating export failure rather than reporting a false success. This is classified with #434 as a 0.9.1-rc bug fix. Review will verify explicit persistence versus automatic refresh semantics, first-export quality selection, artifact failure behavior, and compatibility with the existing incremental artifact stack.

[DeusData]

Thanks for this, and apologies for the slow acknowledgement. Queued for review.

Currently CONFLICTING against main with CI green (20 checks) — a rebase is the only mechanical blocker. The incremental-indexing area has moved recently, so rebasing will also tell you quickly whether the change still lands the way you intended.

[mvanhorn]

The Windows job failure looks like a timing flake in an unrelated test rather than anything from this PR.

The run is 3669 passed / 1 failed, and the one failure is:

daemon_ipc_windows_rendezvous_bridges_concurrent_lifetime_owner
  FAIL tests/test_daemon_ipc.c:1163: ASSERT(startup_observed)

startup_observed is set by a bounded poll -- 200 iterations of cbm_usleep(1000), so a fixed ~200ms budget -- waiting for a background thread to take cbm-startup-v2.lock. If the runner is loaded enough that the thread doesn't acquire it inside that window, the flag stays false and the assert trips. That Windows job took 17 minutes on this run, so a 200ms race losing is plausible. ci-ok then fails only because it aggregates test.

This PR touches src/pipeline/pipeline.c, pipeline.h, pipeline_incremental.c and tests/test_pipeline.c -- nothing in the daemon or IPC paths, and test_pipeline passes. A re-run should clear it; I can't trigger one.

If it's worth hardening, raising that poll budget or waiting on the lock rather than sampling it would make the test deterministic -- happy to send that separately.