[WIP] When multiple pipelines run in parallel against the same repo, they crea

[bamdadd]

⚠️ This is a draft PR created by Lintel after a pipeline failure.
The automated workflow could not complete successfully. An engineer should review the changes, fix any issues, and mark the PR as ready.

Summary

Resolve parallel pipeline repo conflicts by adding a rebase_node before raise_pr (with needs_rebase re-queue on conflict), serialising per-repo execution via PostgreSQL advisory locks, storing repo lock state in pipeline metadata, and propagating all new statuses/events through contracts, projections, and the settings API.

Changes

• Add contracts: needs_rebase status, new events, rebase_branch Protocol method
• Implement rebase_branch in GitHub repo adapter with typed conflict error
• Add repo-scoped advisory lock helper to coordination package
• Add repo_concurrency_limit setting to settings API
• Update pipeline store to support repo_id queries, needs_rebase status, and repo_lock metadata
• Add rebase_node to LangGraph workflow and wire graph edges
• Update projections to handle PipelineNeedsRebase and PipelineRequeued events
• Write tests for contracts, repos rebase, coordination lock, pipelines-api store changes
• Write tests for rebase_node workflow and end-to-end conflict resolution flow

Context

When multiple pipelines run in parallel against the same repo, they create branches from the same base. The second PR to merge will have conflicts with the first. This causes silent failures or broken PRs.

Implementation:

1. Before raise_pr stage, rebase the working branch on latest main and re-run tests
2. If rebase conflicts, mark the pipeline as needs_rebase and re-queue it
3. Add an optional per-repo concurrency limit (default 1) so pipelines targeting the same repo are serialised
4. Store repo lock state in the pipeline metadata so the executor can check before starting implement

---

Raised by Lintel 🤖

[bamdadd]

Closing stub PR — implement stage failed, will retry with fix.