[aeddi]

Summary

Gives every job a timeout-minutes — the six in ci.yml and the nightly one in
security_audit.yml. Without one a hung job holds a runner until GitHub's six-hour
default.

The audit job matters most of the three files: it runs on a schedule:, where a hang
is least likely to be noticed, and it would otherwise have been the only job in the
repository still unbounded. release.yml already had one.

The values catch a hang; they are not performance budgets. Legs on run 41644686566
take 0 to 3 minutes, so the limits sit well above anything a healthy run does — too
tight would buy flaky failures, which is worse than the hang.

job	limit
build, test	30
check, clippy	20
cargo-deny, security_audit	15
rustfmt	10

All eight jobs across the three workflows are now bounded, release.yml's 45 included.

Why now

Raised while reviewing #3. That PR set fail-fast: false, which removes an incidental
backstop: under fail-fast: true a hung leg was cancelled whenever a sibling leg
happened to fail. That was never a timeout and only fired when something else broke,
but it did sometimes cut a hang short.

Scoped to all six jobs rather than the two #3 touches, because fixing two would leave
the file inconsistent. release.yml:29 already had one.

Verification

• actionlint — clean on all three workflows
• parsing every workflow reports 8 jobs, 0 unbounded — checked structurally rather
  than by reading

That clean result is load-bearing, not merely a well-formedness check. Both mutants
die:

• timeout-minute — rejected: unexpected key "timeout-minute" for "job" section
• timeout-minutes nested under strategy:, where GitHub would not read it as a job
  timeout — rejected: unexpected key "timeout-minutes" for "strategy" section

So actionlint validates the spelling and the placement of this key.

What this does not show: a timeout only fires on a job that hangs, and nothing here
hangs. As with #3, the evidence is that the key is correct and validated, not that the
limit has been observed to cut anything off.