release-please: use `queue: max` on the concurrency group once actionlint accepts it

[kojiromike]

#39 puts the release-please-reusable.yml job in a repo-wide concurrency group so that duplicate runs for one push wait instead of racing. GitHub's default for a group is queue: single: one pending run, which a newer run cancels. When three runs overlap (for example, a push that GitHub starts twice while an earlier run is still going), one of them ends cancelled. No release work is lost, because the surviving run reads the branch's current HEAD. But a canceled check rolls the commit's status up as a failure, which is the kind of noise #39 set out to remove.

This will happen in practice. Replaying each caller's last 100 Release Please runs through a one-running, one-pending queue predicts 37 canceled runs out of 1,354, across 9 repos, where merges land seconds apart. Those same runs had 28 failures from all causes.

queue: max keeps up to 100 pending runs and cancels only beyond that, and it is valid alongside cancel-in-progress: false (workflow syntax: concurrency).

Blocker: actionlint rejects the key. parseConcurrency in parse.go accepts only group and cancel-in-progress, in both openCoreEMR/actionlint@v1.7.12-oce.2 and upstream rhysd/actionlint main, so this repo's actionlint check would fail. Upstream has an open PR for it (rhysd/actionlint#654, tracking issue rhysd/actionlint#657).

To do

1. Teach the actionlint fork to accept concurrency.queue (cherry-picking concurrency: Add support for queue key rhysd/actionlint#654 is the likely route), release it, and bump the pin in .github/workflows/actionlint.yml.
2. Add queue: max to the concurrency block in .github/workflows/release-please-reusable.yml.
3. Drop the one-pending-run caveat from the job comment and from the README paragraph on the concurrency group.

Done when three overlapping Release Please runs in one caller repo all finish green.