[cryptodev-2s]

Explanation

Adds docs/processes/dependency-upgrade-tooling.md so we can settle whether to keep Dependabot or Renovate, and indexes it from docs/README.md.

It compares what each tool can do rather than how we happen to have them configured, since anything we never switched on is not a limitation. Every capability claim cites the vendor's docs or source, and the appendix has the command to reproduce every number.

The most useful thing in it is a finding that removes the alert backlog from the decision entirely. All 139 open alerts are recorded against yarn.lock, and 124 of them are on transitive dependencies. Dependabot has already raised pull requests for all 15 alerts on the 3 direct dependencies. Neither tool can fix the rest: Dependabot only moves a transitive dependency when the tree already permits it, and Renovate removed transitiveRemediation outright. The levers are upgrading parents or a resolutions override.

So this is a choice about ergonomics at volume, not capability, and the document says so instead of recommending a winner. It proposes testing the two things we have never tested, Dependabot groups with applies-to: security-updates, and whether Renovate opens a [SECURITY] pull request at all.

Three claims I made earlier in this work are corrected in the document rather than quietly dropped:

• Dependabot security updates do not split version ranges across workspaces. chore(deps): bump the npm_and_yarn group across 1 directory with 20 updates #8849, chore(deps): bump the npm_and_yarn group across 23 directories with 1 update #9369 and chore(deps): bump @metamask/snaps-sdk from 11.2.0 to 12.1.0 #10025 all bump consistently. That was the original argument for switching and it does not hold.
• Grouping is not Renovate only. Dependabot supports groups including applies-to: security-updates.
• Renovate exempts security fixes from its age gate by default, exactly like Dependabot.

Also states plainly that security updates ignoring cooldown, open-pull-requests-limit and allow is correct behaviour we want, not a defect, so nobody relitigates it.

References

Part of WPC-1161.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them