ci: suppress CODEOWNERS auto-tagging on release-branch PRs

[jth-nw]

What

Adds .github/workflows/suppress-codeowners-on-release.yml, which empties .github/CODEOWNERS once on any newly created release/* branch.

Why

GitHub resolves code owners from the base branch of a pull request. Release branches are cut from dev and inherit its full ownership map, so any large or cross-wired PR targeting a release branch auto-requests every doc team.

This recently happened on PR #1171 (reapply-pr-1032-stateintime-note → release/auditor_10.9): the branch fell ~243 commits behind, a sync temporarily ballooned its diff to 200+ files spanning every product, and all doc teams were tagged — even though the final merged diff was only 2 files.

Emptying CODEOWNERS on release branches scopes code-owner auto-requests to PRs targeting dev, where the full ownership map lives. (Code-owner auto-requests fire regardless of branch protection, so this per-branch CODEOWNERS file is the only native lever.)

How

• Triggers on the create event, gated to release/* branches. The workflow must live on the default branch (dev) for create to fire it.
• Feature branches and main are untouched.
• The ref is passed via an env var (not interpolated into the shell) per GitHub's script-injection hardening guidance.
• Pushes use GITHUB_TOKEN, so they don't retrigger CI or loop.

Follow-up (not in this PR)

The already-existing release/auditor_10.9 needs a one-time empty-CODEOWNERS commit pushed directly to it — the Action only covers branches created from now on.

🤖 Generated with Claude Code

[github-actions]

Code Review

Scope: one new workflow file (.github/workflows/suppress-codeowners-on-release.yml). No products.js / docusaurus.config.js / sidebar / KB-script changes in this PR, so build, routing, and the KB pipeline are unaffected.

Overall the workflow is well-constructed. A few things to be aware of — none are hard blockers, but the first is worth confirming.

Observations

1. [Info] create-triggered workflows only run from the default branch. Per GitHub docs, a workflow triggered by on: create runs only if the workflow file exists on the repository default branch (main). This PR targets dev, and dev only reaches main via the daily sync-dev-to-main job. So the suppression will not be active until this file lands on main — having it on dev (or on a freshly cut release branch) is not enough. Flagging the activation lag; the logic itself is correct.

2. [Low] git diff --quiet will not detect an untracked CODEOWNERS file. In the intended scenario the release branch inherits a tracked .github/CODEOWNERS from dev, so emptying it produces a diff and the commit/push fires correctly. But the mkdir -p .github plus printf > .github/CODEOWNERS path also handles the case where the file is absent — and there the newly written file is untracked, so git diff --quiet -- .github/CODEOWNERS reports no change and the step prints "already empty; nothing to do" without committing. More robust: git add the file first, then test with git diff --cached --quiet. Low severity given the file currently exists and is tracked.

3. [Low/Info] Push may fail if release branches are protected. The job pushes a bot commit directly to HEAD:release/* using the default GITHUB_TOKEN. If release branches enforce PR-only updates, required status checks, or signed commits, that push is rejected and the job fails. Worth confirming release branches permit direct bot pushes (otherwise the job surfaces a red X on every release cut).

Looks correct

• No workflow-recursion loop: the commit is pushed with the default GITHUB_TOKEN, which by design does not trigger further workflow runs — so this will not re-fire itself or kick off build-and-deploy.
• Script-injection hardening is right: github.event.ref is passed via the TARGET_REF env var in the push step rather than interpolated into the shell. The actions/checkout ref input is an action input (not shell), so it is safe.
• Permissions are minimal and correct: contents: write is exactly what the push needs, nothing more.
• Event gating is correct: create cannot be ref-filtered in on:, and the job-level if: ref_type == branch and startsWith(github.event.ref, release/) correctly scopes it. On create, github.event.ref is the short branch name (e.g. release/x), so both the checkout ref and the HEAD:$TARGET_REF push refspec are right.