ci: hold major updates for dashboard approval, so lock-file maintenance gets a slot

[sgort]

Refs #97. This corrects part of #103's reasoning, based on what was observed right after it merged.

What #103 got wrong

#103 gave lock-file maintenance prPriority: 10, on the reasoning that it would take the first slot that freed. That was sound but insufficient, and the evidence arrived within minutes:

• fix(deps): update frontend dependencies #85 and fix(deps): update backend dependencies #86 were merged to free two slots below prConcurrentLimit: 5.
• One slot was taken almost at once by an unrelated update, chore(deps): update github actions #104.
• The Dependency Dashboard showed three more rate-limited updates waiting for the other slot, all eligible any day.

Priority only orders branches that are eligible in the same run, and lock-file maintenance is eligible only inside its Monday schedule. During the week, everything else fills each free slot first. Priority alone would never have kept one open for Monday.

The fix

The queue competing for those slots was almost entirely major updates:

• npm 12;
• a backend major group of 17 packages, including express, eslint, jest and typescript;
• a frontend major group of 15 packages, including vite, tiptap, eslint and jsdom.

Nobody merges those on autopilot anyway. They now need Dependency Dashboard approval. Each one waits in #36 as a checkbox and holds no slot until someone ticks it. That leaves the five slots for minor and patch updates and for lock-file maintenance.

vulnerabilityAlerts sets dependencyDashboardApproval: false explicitly, so a security fix that happens to be a major version never waits on a click.

Corrections

The prPriority rule's description and the posture page's account of #97's closure both said priority makes lock-file maintenance take the first free slot. Both now describe what was observed: priority is the weaker half, and the approval rule is what keeps the slot open.

Early evidence for #103's grouping fix

The Dependency Dashboard now lists one lock-file-maintenance entry. Before #103 it listed three. That is direct evidence the grouping fix works, ahead of Monday's scheduled run.

After merge

• The rate-limited majors reappear in Dependency Dashboard #36 as approval checkboxes.
• The majors already open (chore(deps): update dependency concurrently to v10 #68, chore(deps): update dependency lint-staged to v17 #69, chore(deps): update dependency node to v24 #80) stay open. The rule governs how new majors are created, not existing pull requests. That leaves the queue at four of five, with one slot for Monday.
• Monday 14 September, before 05:00: one lock-file-maintenance PR should be created. That closes both of The transitive dependency tree is neither maintained nor tested: lockfile-only changes skip CI, and Renovate's refresh was starved #97's remaining conditions.

Verification

renovate-config-validator --strict passes at the version CI pins (44.50.3). check-format and check-supply-chain pass. The only files touched are renovate.json and the docs, so nothing deploys.