[IMPROVEMENT] Define post-push PR monitoring and remediation workflow

[muddlebee]

Current state

CI.md defines local pre-push checks, focused test selection, and CI-only coverage, but it does not define what an agent or contributor must do after pushing a PR.

As a result, PR creation can be treated as completion even while:

• required Actions or CodeQL checks are pending or failing;
• review feedback exists in GitHub reviews, inline threads, or issue comments;
• Greptile reviewed an older head commit or has unresolved comments;
• a deterministic failure is repeatedly rerun instead of fixed.

A documentation-only approach was explored in #4832 and intentionally closed so the workflow and automation boundary can be designed first.

Desired state

Define one reliable post-push monitoring and remediation workflow, then document the agreed contract in CI.md.

The design should cover:

1. Verify the remote PR head SHA matches the local commit before waiting for or triggering reviews.
2. Monitor all required Actions shards, CodeQL, synthetic tests, and other installed checks.
3. Inspect human reviews, changes-requested states, issue comments, inline comments, and unresolved review threads—not only check runs.
4. When Greptile is configured, require a current-head 5/5 score with zero unresolved Greptile threads.
5. On actionable failures, inspect the full context, fix the root cause, run focused local validation, push to the same PR branch, and restart monitoring for the new head.
6. Rerun without a code change only for credible flaky or external failures.
7. Stop only when the PR is mergeable, required checks are green/neutral, and actionable feedback is resolved—or report a concrete external blocker.

Design questions

• Should this remain an agent/contributor policy in CI.md, become a reusable local command, or use a GitHub App/workflow?
• What permissions are safe for automated fixes, especially for fork PRs and untrusted code?
• How should the loop avoid stale review scores, duplicate Greptile triggers, infinite fix cycles, and unauthorized thread resolution?
• Which reviews are mandatory versus advisory, and how should unavailable third-party services affect the exit gate?
• Should monitoring stop at “ready to merge,” or may automation enable/perform merge under repository rules?

Acceptance criteria

• The trust and permission boundary is documented before enabling write automation.
• The workflow checks the published head SHA before consuming review results.
• CI/security checks and every GitHub review surface have explicit handling.
• Current-head Greptile score and unresolved-thread handling are defined when Greptile is installed.
• Deterministic failures require a fix; reruns are limited to justified flaky/external failures.
• Exit conditions, retry limits, and blocked-state reporting are explicit.
• CI.md is updated only after the workflow design is agreed.

[shantanu-1607]

hi @muddlebee , i would like to work on this issue. can i be assigned this? thanks!