chore: request code owners only on pull requests that reach next

[AztecBot]

Problem

Since #25435 set CODEOWNERS for the Foundation-owned components, owners are being
requested on pull requests that are not headed for next — stacked pull requests
whose base is another pull request's branch — and re-requested every time the stack
is rebased.

That is how GitHub's native CODEOWNERS works, and there is no setting that changes it:
the file is read from the pull request's base branch, every feature branch cut from
next carries a copy, and owner assignment re-runs when the base moves. Observed on
#25436: each review_requested event lands in the same second as a
base_ref_force_pushed, and the PR has had four further base_ref_changed events
since.

What this does

Requests owners only when a pull request's merge reaches next:

• base is next, or
• base is a merge train that targets next — every merge-train/* except the
  -v<N>-suffixed ones, which target their release line (the same rule
  merge-train-create-pr.yml uses to open the train's own pull request).

Stacked pull requests request nobody. Rebasing a stack requests nobody. When the pull
request under a stack merges and the next one is retargeted onto next, owners are
requested once, at that moment.

How

1. CODEOWNERS is renamed to .github/next-code-owners, content unchanged apart from an
   explanatory header (Git records it as an 80%-similar rename). GitHub reads only the
   exact name CODEOWNERS, so once renamed it requests nobody natively, on any base.
2. .github/workflows/codeowner-notify-next.yml runs on pull_request_target for
   opened, ready_for_review, and edited (the last only when the edit changed the
   base), prefiltered to next and merge-train/** so ordinary pull requests start no
   job. Drafts are skipped. It checks out only the two files it needs, from the base
   branch — never the pull request's head — so the elevated token is not exposed to code
   from the pull request.
3. .github/scripts/next_code_owners.py applies the file with CODEOWNERS semantics:
   last matching pattern wins per changed path, reviewers are the union across paths,
   @org/team becomes a team reviewer, and the author is dropped (GitHub rejects
   requesting the author).

Preserving last-match-wins matters here: the file relies on it and says so in its own
comments — /barretenberg/ sits above the AVM block so the AVM team re-claims vm2,
and the protocol-contracts rule precedes the public_context.nr line for the same
reason. A union-of-all-matches matcher would ping the bb team for AVM changes.

Tests

22 cases against the real file, all passing:

• Precedence: vm2/foo.cpp → AVM team only; public_context.nr → AVM, not protocol;
  private-kernel-init/ → kernel owners (no IlyasRidhuan); rollup-base/ → rollup
  owners; crates/types/ → the broad circuits rule; two files → union of both winners.
• Deliberate non-owners stay silent: mock-protocol-circuits, yarn-project/,
  avm-transpiler/Cargo.lock (while Cargo.toml is owned).
• Base rule: next, merge-train/barretenberg, merge-train/docs notify;
  merge-train/spartan-v5, v5-next, cb/blob-fracs-halving (the stacked base from
  test(blobs): pin the fracs hint's root-of-unity contract and widen its coverage #25450), ad/feature do not.
• Author dropped while co-owners are kept; a base with no owners file (a merge train that
  has not pulled next yet) requests nobody rather than failing.

What is given up

GitHub's native code-owner features stop applying on next: the "code owner" badge on
review requests, owner hints in the Files-changed view, and the
require_code_owner_review ruleset option, which #25435 named as a possible next step.
Reversing is a rename back.

Rollout

pull_request_target runs the workflow from the base branch, so this takes effect on
next at merge and on each train once it has pulled next. Trains outside the auto-pull
loop (docs, fairies, spartan, test-train) keep the old native CODEOWNERS — and
its native behaviour — until someone merges next into them. v5-next is untouched.

The private repo receives this through the public → private sync; the two files are
byte-identical today.

---

Created by claudebox · group: slackbot · requested by Mike (@iAmMichaelConnor) · Slack thread