Add parallel-steps rule: check wait/cancel references and steps allowed inside parallel

[devantler]

🥞 Stacked on #694 — please review/merge after it. GitHub can't base a cross-fork PR on another fork's branch, so the base here is main: the diff includes #694's commits and narrows to just this rule once #694 merges.

Summary

Adds a parallel-steps lint rule for the new parallel steps feature, catching two classes of mistake the parser alone doesn't:

1. wait/cancel references — a wait: <id> / cancel: <id> must refer to the ID of a preceding background: true step (analogous to how needs: refers to job IDs), so a typo like cancel: typo is flagged.
2. Steps inside a parallel group — a parallel group may contain only run/uses steps; background, wait, wait-all, cancel, and a nested parallel are all rejected.

The first addresses the remaining review point on #694; the second extends the rule to the structural constraints GitHub enforces.

wait/cancel references

RuleParallelSteps walks each job's steps in document order (recursing into parallel: groups), tracking the IDs of background: true steps seen so far. A wait/cancel target that isn't among them is reported:

"serverr" is not the ID of a preceding background step. "wait" and "cancel" steps can only refer to an earlier step that has "background: true" [parallel-steps]

A single in-order pass checks three things at once: the target exists, is a background step, and precedes the reference. wait-all and expression-valued IDs (${{ }}) are skipped to avoid false positives.

Steps inside a parallel group

A parallel group only allows run/uses steps — verified against actions/languageservices' workflow-parser (shared by the backend and the VS Code extension), which rejects the rest at parse time. Each is reported:

- parallel:
    - run: echo build
      background: true   # "background" is not allowed for a step inside a "parallel" group …
    - wait: other        # "wait" step is not allowed inside a "parallel" group
    - wait-all:          # "wait-all" step is not allowed inside a "parallel" group
    - cancel: other      # "cancel" step is not allowed inside a "parallel" group
    - parallel:          # "parallel" step cannot be nested in another "parallel" step
        - run: echo nested

A step that's forbidden here is reported once — its wait/cancel reference isn't separately re-validated, so there's no cascading "unknown reference" error from the same step.

Tests / docs

• New rule rule_parallel_steps.go, registered after RuleJobNeeds in linter.go.
• testdata/err/parallel_step_refs.{yaml,out} — unknown / non-background / forward references, plus every disallowed step inside parallel.
• testdata/ok/parallel_step_refs.yaml — dynamic background: ${{ … }} treated as a possible background step and expression-valued references skipped; testdata/ok/parallel_steps.yaml covers valid run + uses inside parallel.
• docs/checks.md section + TOC entry; SARIF golden updated.
• go test ./... green; gofmt / go vet / staticcheck clean.

🤖 Generated with Claude Code

[devantler]

Still working on this a bit more. I want to be sure that we catch this error scenario:

on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - parallel:
        - parallel: # not allowed. Should fail with actionable feedback.
          - run: echo "not good"

---

Done ✅ The code lints for this scenario as well now.

[devantler]

Now I am investigating whether wait/cancel/background are allowed inside a parallel: group. If not, I want to add linting checks for that also.

EDIT: They are not. I am working on adding linting for this now.

---

Done ✅