chore(renovate): automerge GitHub Action digest re-pins, and only those (#62)

[wormeyman]

Closes #62.

A digest re-pin moves a SHA and the # vX.Y.Z comment beside it, together, and there is nothing else in the diff to read. It also recurs forever. Reviewing it by hand teaches nobody anything and trains the habit of skimming bot PRs, which is worse than automating the boring case. Renovate has one queued right now (pnpm/action-setup → 0ebf471).

{
  matchManagers: ["github-actions"],
  matchUpdateTypes: ["digest", "pin", "pinDigest"],
  automerge: true,
  automergeType: "pr",
  platformAutomerge: true,
}

Why this is safe now and was not this morning

Two things had to be true, and the second arrived last:

1. verify is a required status check on main (ruleset EJ, bypass_actors: []), so an automerged PR cannot land red.
2. strict_required_status_checks_policy: true (Harden the main ruleset: no pull-request requirement, non-strict status checks, and a duplicate ruleset #60, a few minutes ago), so it cannot land having passed against a different main than the one it merges into.

(2) is the specific objection I recorded against doing this earlier - "not yet, because a PR can pass against an old main". It is now closed, so the reasoning that deferred this no longer applies.

Consequence, stated in both the config and CLAUDE.md: this rule is NOT independently safe. If bypass actors are added, verify is dropped, or strict is turned off, the rule must be removed in the same change. It borrows its safety entirely from branch protection.

platformAutomerge hands the merge to GitHub's own auto-merge, so the required check gates it rather than Renovate polling and merging itself.

What stays manual, and why it is not caution-by-default

Everything else, under the existing global automerge: false. The reason is on the record rather than a preference: pnpm run verify proves the repo is CONSISTENT, not that a bump is CORRECT. pako 3.0.0 flipped legacyHash to false, which passes a green suite while silently breaking the codec's byte-exactness - and the wrong belief that produced ("pako cannot match zlib") survived roughly a year and was hardened into CLAUDE.md and issue #40 before #46 refuted it. test/deflate.spec.ts now guards that specific option, but the general lesson stands.

Explicitly out of scope, permanently: the codec path (pako above all), vite-plus, vue/pinia/vue-tsc, the wrangler pair, .node-version, and the factoriotools/factorio Docker digest - that last one pins the render container to a game version, which is a fixture-provenance decision, not a dependency bump. A comment above the remaining packageRules now says so, so the next reader does not have to infer it from the absence of a rule.

Also corrects CLAUDE.md

It still said "Branch protection on main is not configured", which is false as of #60. Replaced with the actual state, plus the two things that are load-bearing and easy to break by tidying:

• required_approving_review_count is 0 on purpose - GitHub will not let you approve your own PR, so 1 would make main unmergeable by its only maintainer.
• Protection is a ruleset, so gh api .../branches/main/protection returns 404 on a protected branch here. That reads exactly like "unprotected" and is not; the right call is gh api .../rules/branches/main.

Verification

renovate-config-validator exit 0 after the formatter pass (which rewrote quoting, so it was re-validated afterwards rather than before). vp check clean - 301 files, no warnings/lint/type errors. CI verify runs on this PR.

Note what this PR cannot demonstrate: the automerge path itself only exercises on the next Action digest PR. If that lands without human action and stays green, it worked.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F3a2HLJ4beKARi7SPmaM54