SCM multi-PR sessions inject CI/review feedback as low-context single-PR nudges

[neversettle17-101]

Bug

Sessions can now own multiple PRs, including stacked PRs, but SCM lifecycle injection still sends low-context, single-event nudges. When more than one PR in a session has failing CI or review feedback, the agent receives separate messages with generic wording like "your PR" and no PR number/branch context. If one PR has both failing CI and review comments, lifecycle returns after the CI nudge and does not inject the review feedback in the same pass.

Source: user report in Codex chat on 2026-07-04
Analyzed against: e74fb65a853f64bc4c8bfec2720cc078b572a3a5
Confidence: High for current behavior; medium for exact product impact without a live multi-PR repro capture.

Reproduction

1. Create or use a worker session that owns multiple PRs, for example a root PR on feat/x and a stacked child PR on feat/x/auth.
2. Have more than one PR require attention, such as failing CI on one PR and unresolved human review comments on another.
3. Let the SCM observer poll and lifecycle inject messages into the worker session.
4. Observe that messages are injected per PR with generic wording and no stack/PR context. If a single PR has both failing CI and review comments, only the CI nudge is sent for that lifecycle observation.

Root Cause

The core SCM/storage/status path is multi-PR aware, but lifecycle injection is still shaped like a single-PR reaction:

• backend/internal/observe/scm/observer.go discovers and persists multiple PRs per session by branch-prefix matching (discoverNewPRs) and then calls lifecycle once per observed PR.
• backend/internal/lifecycle/reactions.go:149 handles failing CI first and returns after sending the first failed-check nudge.
• backend/internal/lifecycle/reactions.go:163 handles review feedback only if the CI branch did not return first.
• backend/internal/lifecycle/reactions.go:159 / :172 dedup by PR URL, so separate PRs can send separate nudges, but the message body does not identify PR number, source/target branch, stack position, or other sibling PR context.
• The observer iterates the observation map, so multiple PR nudges may arrive in nondeterministic order.

This means multiple PRs are tracked correctly in storage/status, but the agent-facing SCM feedback is not composed for a multi-PR session.

Expected Behavior

For a session with multiple PRs, SCM feedback sent to the agent should be explicit and actionable:

• Include PR number/title/URL and source -> target branch for every CI/review item.
• Batch multiple attention items in a deterministic order, preferably by stack/root and severity.
• If one PR has both failing CI and review comments, include both or send two clearly labeled nudges without one silently suppressing the other.
• Preserve per-PR dedup semantics so already-delivered feedback is not repeated.
• Keep the current suppression for terminated sessions and waiting-input sessions unless the product decision changes.

Suggested Fix

Introduce a session-level SCM attention composer in lifecycle, or extend the observer/lifecycle handoff so a poll can deliver a deterministic batch of changed PR attention items for a session.

A pragmatic slice:

1. Keep per-PR persistence and semantic hashes unchanged.
2. Build a lifecycle message payload containing all newly changed actionable items for the session: CI failures, unresolved review comments, and merge conflicts.
3. Include PR identity and branch context in each item.
4. Preserve dedup keys per PR/item, but send a single session message when multiple items are new in the same poll.
5. Add regression tests covering:
   • two PRs in one session both need attention;
   • one PR has CI failure and review comments;
   • stack child feedback includes child PR identity;
   • repeated polls do not duplicate already-delivered items.

Impact

• Agents can receive ambiguous or incomplete instructions in multi-PR sessions.
• Review feedback can be delayed or effectively hidden behind a CI failure for the same PR.
• Stacked PR workflows are harder to recover because feedback lacks PR/branch context.

[neversettle17-101]

@Pritom14 @iamasx FYI