rule: require CARGO_BUILD_JOBS / SOLDR_JOBS to be unset in workflows #30

Problem

Workflows sometimes pin build parallelism, e.g.:

env:
  CARGO_BUILD_JOBS: "1"
  SOLDR_JOBS: "1"

In zackees/zccache the Integration prebuild (cargo test --no-run, compile only) was pinned to 1 job. That made the slowest PR job's biggest step (median 7.3 min) run on one core of a multi-core runner. Pinning a number ("4") is also wrong: it goes stale when runner sizes change. Left unset, cargo and soldr already default to every available core. Fixed in zackees/zccache#1800.

Proposal

Add a rule that flags CARGO_BUILD_JOBS and SOLDR_JOBS (and -j/--jobs on cargo/soldr command lines) set anywhere in a workflow or composite action: workflow-, job- or step-level env, or exported in run:.

• They should be unset by default.
• Allow an explicit, justified exception, e.g. a trailing # ci-lint: allow <RULE> <reason> comment. A step that runs timing-sensitive tests might legitimately serialize.
• The rule must match setting lines only, not comments that mention the variable names.

Tests

Fixtures for this rule:

• red: a step sets CARGO_BUILD_JOBS: "1"
• red: a workflow-level SOLDR_JOBS: "4"
• red: cargo build -j 2 in run:
• green: no setting at all
• green: a comment that mentions CARGO_BUILD_JOBS
• green: an allowed exception carrying a reason