startup_failure with zero jobs is also actor-level: a CodeRabbit-created PR head starts no workflow runs while the workflow tree is unchanged #1266

Symptom

A pull request's head commit produced startup_failure on every workflow — run created, zero jobs, nothing in the log, gh run rerun refuses with "cannot be rerun; its workflow file may be broken" — while the workflow files at that commit were byte-identical to the previous head, whose eight workflows all ran to success.

This is a second, independent mechanism reaching the same symptom as #968 (silently dead runs, startup_failure, jobs=0). It is not a lock desync and not a YAML defect: it is the push actor.

Evidence — hyperpolymath/rpa-elysium, PR #149, 2026-10-14

gh api "repos/hyperpolymath/rpa-elysium/actions/runs?head_sha=626d9df...&per_page=10" \
  --jq '.workflow_runs[] | "\(.event) \(.actor.login) \(.triggering_actor.login) \(.conclusion)"'
# pull_request coderabbitai[bot] coderabbitai[bot] startup_failure   (x8, jobs=0)
gh api "repos/hyperpolymath/rpa-elysium/actions/runs?head_sha=2c851fa...&per_page=10" \
  --jq '.workflow_runs[] | "\(.event) \(.actor.login) \(.conclusion)"'
# pull_request hyperpolymath success (and in-progress for the slow jobs)

626d9df was created by CodeRabbit's "Commit suggestion" flow (author and committer coderabbitai[bot], pushed from the review UI). Re-creating the same tree under the repository's own identity started CI immediately. git diff 41b0256 626d9df -- .github/ is empty.

Why it matters estate-wide

Any repo that lets a GitHub App (CodeRabbit, Renovate-style autofix bots, or "commit suggestion" flows) create the head commit of a PR gets a PR with no CI at all, reported as startup_failure rather than a missing check. Required status checks never report, so the PR is blocked in a way that looks like a workflow bug; the repairs attempted from the YAML side cannot succeed because the YAML is not the cause.

The reverse trap also exists: if startup_failure is treated as "broken workflow file" by an audit, the audit will report a phantom YAML defect on a head that is fine.

Suggested handling

1. For a triage rule: a head where every workflow is startup_failure with jobs=0 and the workflow tree is unchanged from a working head is an actor-level failure, not a content-level one — compare actor.login / triggering_actor.login across the two heads before editing any workflow.
2. For repos that use app-side "commit suggestion": re-create the head under a human/CI identity (an amend keeps the tree), or configure the app's commits to be attributed to the pusher.
3. For lock/state audits (including the one behind standards#968): distinguish "workflow references an unlocked action" from "no run started", because both produce startup_failure with jobs=0.

Measured while closing hyperpolymath/rpa-elysium#143; recorded in that repository's docs/CI-CD-REPAIR.adoc with the same evidence.