Summary

check-additional is failing across multiple unrelated PRs because gateway-watch-regression invalidates early with dirty_watched_tree, even when the PR diff does not touch gateway watch logic and local reproduction on the PR head passes.

Evidence

Observed on these unrelated PRs:

• #65771 fix(cron): surface timeout cause before raw errors
• #65691 Slack action-runtime changes
• #65777
• #65781
• #65793

Common pattern:

• check-additional fails
• check, checks-node-core-runtime, checks-node-agentic pass
• artifact gateway-watch-regression only contains:

  {
    "invalidated": true,
    "invalidationReason": "dirty_watched_tree"
  }

Example failing run on #65771:

• CI run: 24333912468
• artifact: gateway-watch-regression
• summary shows dirty_watched_tree invalidation before the bounded watch window check could produce a meaningful result.

Local reproduction

On the #65771 head (6f2d035b69), running the same harness locally passes:

node scripts/check-gateway-watch-regression.mjs --output-dir /tmp/gateway-watch-regression-local

Observed local summary:

• watchTriggeredBuild: false
• watchBuildReason: null
• addedPaths: 0
• removedPaths: 0

Why this looks like a shared CI/gate issue

At least one of the affected PRs (#65691) only changes Slack action-runtime files, which makes it unlikely that all of these PRs independently introduced the same gateway watch dirty-tree regression.

Suspected area

The invalidation appears to come from the preflight resolveBuildRequirement(...) / watched-tree cleanliness gate inside scripts/check-gateway-watch-regression.mjs / scripts/run-node.mjs, rather than from the feature patches themselves.

Impact

This makes unrelated PRs look unstable and adds noise to CI triage by failing a shared gate before the actual regression harness can evaluate runtime behavior.

Request

Please investigate why CI is reporting dirty_watched_tree for these PR heads when the same heads appear clean and the local harness passes.