Flag hardcoded-secret patterns in workflows for human review

[exploreriii]

🧑‍💻 Intermediate Issue — a complex task spanning multiple modules, with real design decisions to own.
Time: ~25 hours · Prerequisites: comfortable navigating this repo (a completed beginner issue is the usual route; demonstrated CI/CD proficiency substitutes for workflow-focused issues).
We expect more than "it works": maintainable code that fits the existing architecture.

The task

Blocked by #359 — the ci_health engine and findings contract must exist first.

Problem:

The audit checklist requires "no hardcoded secrets in workflow files". This is inherently heuristic — token-shaped literals, token:/password: values not referencing ${{ secrets.* }} — and a heuristic that cries wolf poisons trust in the whole CI-health section. The false-positive design is the task.

What done looks like:

A workflow_secrets check emitting findings with the reserved review status — never fail — so the dashboard presents them as "needs human eyes". Evidence must never contain the matched string: report file:line plus the pattern name only, since findings flow into a public CSV and dashboard. Patterns are documented and individually tested against known-clean fixtures (this repo's own workflows, which reference ${{ secrets.* }} correctly, make a good negative corpus).

Modules involved / constraints: the ci_health engine from #359; the review status semantics defined by its contract. Precision over recall throughout — a short pattern list that never false-positives beats a long one that sometimes does.

How to work on this

1. Claim it: comment /assign and wait to be assigned — unassigned PRs are closed automatically.
2. Get a plan: once assigned, comment @coderabbitai plan for a draft plan, then do your own investigation — docs/architecture.md maps the layers and their rules.
3. Propose your approach as a comment before coding. A paragraph is enough; early feedback here routinely saves days of rework.

🤖 AI: tools are welcome; verified work is required — you can explain every line and defend every design choice. See the AI policy. Fully automated bot PRs are closed.

Worth knowing about this repo before you design:

• The layer rules in docs/architecture.md are strict — review will hold your solution to them.
• Tests mirror src (tests/<pkg>/test_<module>.py), and the output-contract test pins the pipeline output surface — if your change adds or renames outputs, update the contract deliberately.

Before opening your PR:

• I proposed my approach on this issue and incorporated any feedback
• The solution fits the existing architecture and layer rules, and is clear enough for others to debug without me
• Tests cover the happy path, edge cases, and error handling (testing guide)
• I reviewed my own diff line by line; scope is limited to this issue
• Workflow checks pass — CI green, signed commits, linked issue

Stuck? Comment here with what you've tried — see getting help.