ci: managed-scope-sync and state-key-sync run but are not in the ci-status required aggregate

[kyle-sexton]

Summary

.github/workflows/ci.yml defines 38 jobs. The ci-status aggregate — the single required check, whose own comment calls its needs list "the single source of truth for the lane list" — names 34 of them. Two real gates are missing:

• managed-scope-sync (runs scripts/sync-managed-scope.sh --check plus its bump gate)
• state-key-sync (runs scripts/sync-state-key.sh --check plus its bump gate)

Both are listed as dedicated checks in scripts/cross-plugin-source-registry.txt, so the registry advertises an enforcement they do not actually deliver at the merge gate.

Impact

A drifted lib/managed-scope.sh or lib/state-key.sh copy, or a carrying plugin that changed the lib without bumping its version, turns those jobs red while ci-status stays green — and ci-status is what branch protection reads. The failure is visible in the run list and invisible to the gate, which is the same false-green shape the liveness-assertion convention exists to name.

cross-plugin-source-drift is in the aggregate and would catch a drifted copy of either cluster, so this is not a total hole — but it does not cover the --check-bump half (lib changed, carrying plugin version not bumped), which only the dedicated lanes run.

Suggested fix

Add both job names to ci-status.needs. Worth a moment's thought on whether the omission was deliberate for either lane; nothing in the file records a reason.

Related

• Found while verifying docs(conventions): own the Git Bash to Windows path-emit rule and detect its residue #2841 (the PR for Windows verification harnesses: an MSYS /d/ path literal silently redirected two tzdata sabotage cases into a duplicate of case E #2834), which added two jobs and had to establish whether "a new job is automatically required" was true. It is not.
• Refs Windows verification harnesses: an MSYS /d/ path literal silently redirected two tzdata sabotage cases into a duplicate of case E #2834