Fix main CI failure attribution and classification

[Copilot]

Description

The CI failure analyzer could treat failed push runs on main as PR failures, attributing deterministic repository breakage to an unrelated triggering merge and misclassifying it as infrastructure failure.

• Trusted scope
  • Derive main or pull-request scope from immutable run metadata.
  • Validate agent output against the collected scope before publishing.
• Main failure analysis
  • Collect the last successful main SHA and intervening candidate merges.
  • Treat the triggering merge PR as non-causal context.
• Classification and reporting
  • Add main-repository-breakage for deterministic main failures.
  • Create or update labeled [Main CI Failure] issues.
  • Keep PR comments limited to PR-scoped failures.
• Regression coverage
  • Cover scope derivation, non-causal merge context, main-break classification, and trusted-output validation.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

• Fixes [automated] Fix main CI failures being filed as PR infrastructure issues #19454

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

.github/workflows/analyze-ci-failure.md:169

• The main-run context records only each candidate PR's title/URL and then deletes the comparison payload. Because the agent is explicitly barred from querying GitHub, it receives no changed-file or patch data for these merges and cannot verify the semantic conflicts this change is intended to diagnose. Preserve and render the comparison's changed files/patches (or collect equivalent per-PR change data) so attribution can be based on code evidence rather than titles.

                    '. + [$commit + {pull_request: {
                      number: $pr.number,
                      title: $pr.title,
                      url: $pr.html_url,
                      merged_at: $pr.merged_at
                    }}]' ci-failure-data/candidate-merges.json \

.github/workflows/analyze-ci-failure.md:746

• For a main run this row contains main, but reused cause issues created by the old workflow still have a PR column header. The existing-issue path only appends this row and never migrates that header, so stable infra/flaky issues will misleadingly display main as a PR value. Rewrite the legacy header to Context before appending a main occurrence.

              if [ "$RUN_SCOPE" = "main" ]; then
                OCCURRENCE_CONTEXT="main"
              else
                OCCURRENCE_CONTEXT="#${PR_NUMBER}"
              fi
              NEW_OCCURRENCE_ROW="| ${OCC_DATE} | [${RUN_ID}](${RUN_URL}) | ${FIRST_JOB} | ${OCCURRENCE_CONTEXT} |"

.github/workflows/analyze-ci-failure.md:1189

• The schema now permits main-repository-breakage for jobs, but deterministic failed tests on main still have only flaky | code-issue available in both the JSON example and failed_tests[].classification details. That forces a main test regression to be mislabeled as a PR code issue or omitted. Add main-repository-breakage to the failed-test classification contract and example as well.

- `failed_jobs[].classification`: Per-job classification — one of `"transient-infra"`, `"flaky-test"`, `"code-issue"`, or `"main-repository-breakage"`.