main is red: actions.lock omits a transitive dependency of asana/push-signed-commits (actions/setup-python@v2)

[hyperpolymath]

Summary

main is red. scan / Hypatia Neurosymbolic Analysis and governance / Validate Hypatia Baseline
both fail at 9c256b67 (#954), on one high-severity finding that survives the baseline.

The finding

{
  "type": "invalid_actions_lock",
  "rule_module": "workflow_hardening",
  "file": ".github/workflows/actions.lock",
  "severity": "high",
  "action": "regenerate",
  "baseline_status": "new",
  "reason": "actions.lock failed closed: {:transitive_dependencies_missing,
             [{\"asana/push-signed-commits@d615ca88d8e1a946734c24970d1e7a6c56f34897\",
               \"actions/setup-python@v2\"}]}"
}

asana/push-signed-commits@d615ca88 itself depends on actions/setup-python@v2, and the lockfile
records no entry for that transitive dependency. Hypatia fails closed on it, which is the
correct behaviour — this is a real gap, not a scanner defect.

When it started

failure  2026-09-22T10:15:10Z  9c256b67   <- #954
success  2026-09-22T10:10:08Z  be6c9580
success  2026-09-22T09:59:46Z  e977cc67
success  2026-09-22T09:56:48Z  7b05a323
failure  2026-09-22T09:46:37Z  a2ff696a

#954 is titled "asana restore+ack, …". The restore of the asana step is what introduced the
unrecorded transitive dependency.

Note that governance / Actions lockfile verify and uses ⊆ actions.lock are green at the same
commit. They check the workflows' own uses: refs against the lock; Hypatia additionally resolves
each locked action's own dependencies. The two controls ask different questions, and only
Hypatia asks this one.

Acceptance criteria

1. .github/workflows/actions.lock records actions/setup-python as a transitive dependency of
   asana/push-signed-commits@d615ca88d8e1a946734c24970d1e7a6c56f34897, SHA-pinned, or the
   asana step is removed / replaced with an action whose dependencies are lockable.
2. actions/setup-python@v2 is not adopted at a floating major tag — if it is recorded, it is
   recorded at a 40-hex commit, consistent with the rest of the lock.
3. scan / Hypatia Neurosymbolic Analysis and governance / Validate Hypatia Baseline are green on
   main, with findings_kept empty.
4. The fix is not a baseline entry. baseline_status: "new" with action: "regenerate" is the
   scanner telling us the lock is wrong, not that the rule is wrong; baselining it would be muting a
   correct diagnostic.
5. A regression control exists that fails if a locked action's transitive dependency goes
   unrecorded again — or, if Hypatia is judged to be the only reasonable place for that check, this
   issue records that decision explicitly.

Not a blocker on

#962, which inherits both reds from this commit and touches neither
actions.lock nor any uses: ref.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm