ci: run the full gates on testnet-canary PRs

[Jurij89]

Summary

• testnet-canary PRs currently run almost no CI. The vitest lanes, EVM integration, knip and the supply-chain scan are all branch-filtered to [main, v10-rc, release/rc.12, rc17-vm-wip], so a PR targeting canary gets only SPARQL-lint and the path-filtered gates. A change can land on canary with no unit signal at all.
• This was an omission, not a decision. git log -S'testnet-canary' -- .github/workflows/ci.yml returns nothing — the branch was never in the filters. They were last touched on 2026-04-03 to add v10-rc, and testnet-canary postdates that.
• Also drops v10-rc, which no longer resolves (git rev-parse origin/v10-rc → gone). A deleted branch in a filter is dead weight, and it was also used as a turbo restore-key fallback, so that cache tier could never hit; repointed at main.

Related

• Surfaced while retargeting fix(integrations): conform the CLI to the published registry schema #1988 at testnet-canary and noticing the CLI vitest lanes stopped running.
• Ordering note for whoever lands this: see Follow-up below — the protect-main ruleset requires CI gate and EVM integration gate, so a canary ruleset must come after this merges, not before.

Diagrams

• No flow changes — CI trigger configuration only.

Files changed

File	What
.github/workflows/ci.yml	Add testnet-canary to push + PR filters; drop dead v10-rc; repoint the v10-rc turbo restore-key at main
.github/workflows/evm-integration.yml	Same filter update
.github/workflows/knip.yml	Same filter update
.github/workflows/supply-chain-scan.yml	Same filter update

Test plan

• All four workflows parse: npx js-yaml <file> → OK for each
• grep -rn v10-rc .github/workflows/ → only two explanatory comments remain, no live references
• After merge: open or re-push a PR targeting testnet-canary and confirm CI gate, EVM integration gate, Knip dead-code report and the supply-chain scan all appear
• After merge: confirm a push to testnet-canary triggers the same lanes

Follow-up (deliberately not in this PR)

Branch rules are a settings change, not a file change, so they can't ride along here. main is governed by the protect-main ruleset (id 14325863), which targets ~DEFAULT_BRANCH only:

rule	value
pull_request	1 approving review, code-owner review required
required_status_checks	CI gate, EVM integration gate (non-strict)
merge_queue	MERGE, ALLGREEN, up to 5 entries
deletion / non_fast_forward	blocked

These must be applied to testnet-canary only after this PR merges. The required checks are exactly the ones this PR enables — turning them on first would leave every canary PR blocked forever on checks that never run.

Worth a separate decision: whether canary wants the merge queue at all. It adds latency, and a canary branch is usually optimising for iteration speed. The protection rules (no deletion, no force-push, review required) are the parts that matter most.

🤖 Generated with Claude Code

[otReviewAgent]

🟡 Issue: Keep the workflow branch policy descriptions in sync

What's wrong
The PR updates the trigger allowlist from v10-rc to testnet-canary, but leaves branch-specific documentation in the same workflow referring to v10-rc. These workflow files are CI policy, and conflicting branch-policy descriptions make later maintenance harder because readers cannot tell whether v10-rc was intentionally removed everywhere or only from the top-level triggers.

Example
A maintainer searching the workflow for release-branch CI policy now finds both testnet-canary in the trigger lists and stale v10-rc references deeper in the same file, so the intended protected branch set is no longer obvious.

Suggested direction
When changing the canonical branch set in workflow triggers, update the branch-specific policy comments in the same file or make those comments generic enough that future branch rotations do not create conflicting documentation.

For Agents
Review .github/workflows/ci.yml around the trigger updates and the downstream comments that describe branch policy. Preserve the same workflow triggers, but update or remove branch-specific prose so the workflow has a single current branch story.

[Jurij89]

Valid — fixed in aa39a6c58.

One calibration on the framing: the two lines are push (main / v10-rc / …) shorthand whose … already elides the rest of the list, so they were describing trigger shape (push vs PR vs merge_group) rather than declaring a canonical branch set. That doesn't rescue them though — naming a branch that no longer exists in the repo is misleading regardless, and leaving it behind in a PR whose whole purpose is to purge v10-rc is a half-done rotation.

Took the second of your two suggested options — making the prose generic rather than renaming — since that's what stops the next branch rotation from recreating this:

• ci.yml:1025, ci.yml:1206 → push (trigger branches)

Also swept one instance outside the flagged file: .github/CODEOWNERS:3 described branch protection on `main` / `v10-rc`. That one names the branches we genuinely protect rather than illustrating trigger shape, so it got the concrete rename to testnet-canary — which is also the branch the follow-up ruleset will cover.

grep -rn v10-rc .github/ is now empty.

Validation: the diff is comment-only (both changed workflow lines begin with #), and all four workflows still parse to the intended triggers — ci/evm-integration/supply-chain-scan → [main, testnet-canary, release/rc.12, rc17-vm-wip], knip → [main, testnet-canary, rc17-vm-wip].

[otReviewAgent]

🟡 Issue: Branch trigger migration is not covered by workflow-policy tests

What's wrong
This PR changes which branches receive CI, EVM integration, dead-code, and supply-chain scanning, but the existing validation does not prove the trigger filters were updated consistently or spelled correctly. Because branch filters are only interpreted by GitHub Actions, this kind of regression can land green and then remove coverage from the branch it was meant to protect.

Example
A typo such as testnet-canray, or updating ci.yml but missing supply-chain-scan.yml, would still pass the existing repo policy tests while GitHub Actions would silently stop running that workflow for the intended branch.

Suggested direction
Add a small policy test that pins the expected branch trigger sets for the security/CI workflows changed here, ideally from one shared expected branch list per workflow class.

For Agents
Add a workflow-policy regression test near scripts/lib/__tests__/ci-delta.test.mjs that parses the changed workflow YAML files and asserts the intended push/pull_request branch allowlists, including testnet-canary and excluding v10-rc where this PR migrates it. Preserve existing workflow job-wiring checks.