Add Concurrent CI Review Gate

[danchild]

Summary

Reworks the post-PR lifecycle so CI evaluation and human review run concurrently. Previously, workflows blocked at wait_for_ci_gate until all CI checks passed before proceeding to human review. Now, after PR creation the workflow goes directly to human_review_gate and accepts both CI and review webhooks in parallel — matching GitHub's natural PR workflow where merge is the final gate.

Key changes:

• Eliminate the wait_for_ci_gate node; CI webhooks are routed to human_review_gate instead
• Add pending_ci_event state field for buffering CI webhooks at human_review_gate
• Extract shared post-PR lifecycle wiring into post_pr.py (reused by feature, bug, task_takeover graphs)
• Add CI failure attribution phase before attempting fixes
• Fix CI webhook routing to preserve current_node at human_review_gate (prevents premature override to ci_evaluator)

This change is not backward compatible. In-flight workflows checkpointed at wait_for_ci_gate will need to be manually restarted.

Test plan

• All existing unit tests pass (1919 passed)
• Fast Tests & Coverage CI gate passes
• Contract & Workflow Flow Tests pass
• Integration Tests pass
• E2E Smoke Tests pass
• Lint passes
• Container Build passes
• CI webhook at human_review_gate correctly sets pending_ci_event and preserves current_node
• CI webhook at ci_evaluator still routes directly (no pending_ci_event)
• Multi-repo CI webhook activates correct PR record and sets pending_ci_event
• Review gate resume event handling fully covered (12 tests re-added for review_response_gate and human_review_gate behaviors)

Closes #137

[eshulman2]

Automated review: found several correctness regressions in the CI/human-review lifecycle rework that should be addressed before merge. Two additional issues fall outside this diff's changed lines and couldn't be attached inline, noting them here:

src/forge/orchestrator/worker.py (around line 886, in _handle_resume_event) — The dedicated handler that resumed the workflow when a human replied inline to a specific contested-comment thread at review_response_gate (matching in_reply_to_id against contested_comments and clearing only that thread) was deleted with no replacement; only the unrelated PRD/spec-proposal-PR inline-reply path remains (is_proposal_reply check). Failure scenario: a human posts an inline reply on a GitHub review thread that Forge previously contested on an implementation PR. No handling matches this event for review_response_gate anymore, so is_rejected/is_approved are never set and the workflow isn't resumed — the reply is silently ignored. Two tests exercising exactly this behavior (test_inline_reply_resumes_only_its_contested_thread, test_standalone_inline_comment_is_actionable_at_response_gate) were deleted rather than adapted.

src/forge/workflow/pr_state.py (line ~100, save_active_pull_request / _PR_LIFECYCLE_NODES) — This file wasn't touched by the diff but is broken by it: save_active_pull_request still defaults a new PR record's lifecycle_node to the now-deleted "wait_for_ci_gate" node, and _PR_LIFECYCLE_NODES still lists it. Failure scenario: in a multi-repo ticket, create_pull_request calls save_active_pull_request with current_node="teardown_workspace", which isn't in _PR_LIFECYCLE_NODES, so lifecycle_node gets stamped as "wait_for_ci_gate" for every non-final repo. A later /forge skip-gate <name> comment targeting an earlier repo restores that dead node, which is no longer in worker.py's local _CI_STAGES tuple, so the skip-gate command is silently dropped even though the ticket is genuinely at a CI-related stage.

[eshulman2]

Before merging, please provide one of the following for workflows currently checkpointed in the CI stage:

1. Backward compatibility: retain a temporary route/alias from to , including migration of any values that still reference ; or
2. A clear, tested migration path for affected tickets that preserves their existing PR mappings, per-PR CI/review state, and branches.

Simply sending another webhook will resume the existing checkpoint rather than restart it, while clearing the checkpoint can discard PR lifecycle state and cause work to be regenerated. The PR description currently says workflows must be manually restarted, but does not define a safe procedure or provide tooling to identify and migrate affected tickets.

Please document the exact operator steps, expected state transformations, rollback behavior, and tests covering an in-flight workflow at (including a multi-repository ticket).

[eshulman2]

Correction/clarification to my previous review comment:

Before merging, please provide one of the following for workflows currently checkpointed in the CI stage:

1. Backward compatibility: retain a temporary route or alias from wait_for_ci_gate to human_review_gate, including migration of any per-PR lifecycle_node values that still reference wait_for_ci_gate; or
2. A clear, tested migration path for affected tickets that preserves their existing PR mappings, per-PR CI/review state, and branches.

Simply sending another webhook resumes the existing checkpoint rather than restarting it, while clearing the checkpoint can discard PR lifecycle state and cause work to be regenerated. The PR description currently says workflows must be manually restarted, but does not define a safe procedure or provide tooling to identify and migrate affected tickets.

Please document the exact operator steps, expected state transformations, rollback behavior, and tests covering an in-flight workflow at wait_for_ci_gate, including a multi-repository ticket.