CI: harden workflow triggers, action pins and timeouts

[mike927]

Hardens .github/workflows/main.yml after two rounds of review on dependabot's checkout bump. Supersedes #13: actions/checkout is pinned here at v7.0.1's commit SHA, which is the bump that PR was making.

What changed

Supply chain

• actions/checkout is pinned by commit SHA (3d3c42e, v7.0.1) instead of the mutable v7 tag, so a repointed upstream tag cannot change what runs without a diff in this repo. Dependabot maintains SHA pins and the trailing version comment together.
• ruby/setup-ruby deliberately stays on @v1, the reference upstream documents. A pinned release only knows the Ruby builds it shipped with, so pinning it would make the Ruby 4.0 matrix entry planned in ROADMAP 5.2 fail with an unhelpful unknown-version error. The reason is recorded in a comment next to the pin.
• Both checkouts run with persist-credentials: false. No step needs git credentials, and the next step has bundler evaluate gemspec and native-extension code from the branch under test.

Triggers

• push is scoped to branches: [master]. Every branch pushed to this repo was previously building twice, once per event: PR Bump actions/checkout from 5 to 7 #13's head produced two full runs and 16 checks where 8 would do.
• A weekly schedule plus workflow_dispatch. bundler-audit is the only job that can report something new about a tree nobody has touched, so the schedule exists for it and test and the rubocop leg are skipped on that trigger. workflow_dispatch is the on-demand path and also how the cron gets re-armed, since GitHub disables scheduled workflows after 60 days without repository activity.
• A concurrency group cancels superseded runs, but only for pull_request. Cancelling a master run would leave that commit recorded as cancelled rather than green or red, and would kill the run that populates the cache PR runs restore from.

Jobs

• lint and audit were byte-identical apart from the job name and one run, so they are now one checks matrix job. Check names are unchanged (rubocop, bundler-audit).
• timeout-minutes: 30 on both jobs, replacing the six-hour default. Chosen above a cold-cache install rather than from the 10-20s warm runs, because every dependabot lockfile bump misses the bundler cache and installs a full Rails tree from source.

Docs

• CHANGELOG.md gets an [Unreleased] entry. 1.6.0 recorded its CI work the same way.
• ROADMAP 5.2's evidence cited main.yml:15-21 for the six Ruby/Rails pairs, which moved to lines 47-52, and its recommended solution still listed the permissions and concurrency work as outstanding.

For the reviewer

• The one thing not verified locally. The rubocop leg is dropped on the schedule via a conditional include expression, because a job-level if cannot see the matrix context and exclude does not remove include entries. The YAML parses and the folded scalar resolves to the expression intended, but whether GitHub evaluates it into the right legs is only provable by a run. Please confirm the PR run produces exactly rubocop and bundler-audit, and that the first scheduled or manually dispatched run produces bundler-audit alone.
• That expression repeats the bundler-audit entry, since an Actions expression can only choose between whole lists. The tradeoff is noted in a comment above it.
• Merging the two jobs means the bundle exec ... commands now live in the matrix rather than on a run: line, and the audit step's descriptive name ("Check the lockfile against the advisory database") became "Run bundler-audit". A comment in the matrix block carries that explanation instead.
• Scoping push to master means a branch pushed without an open PR gets no CI. That is the intended trade for removing the duplicate runs.
• Bump actions/checkout from 5 to 7 #13 can be closed once this lands. Merging it afterwards would put the mutable @v7 tag back over the SHA pin.

🤖 Generated with Claude Code