feat(renovate): automerge lock file maintenance PRs

[cplieger]

What

lockFileMaintenance joins the automerge allowlist in default.json.

Why

It was left out when 3f827de replaced the global automerge: true with an
explicit update-type allowlist. The effect fleet-wide: the weekly lock file
maintenance batch (~10 repos, one PR per lockfile) went green in about a minute
and then sat until merged by hand. The two batches after that commit were
merged in manual same-second clusters, 14 minutes and 3 days after creation
respectively, and this week's 10 were still open.

That hand-merge reviewed nothing. A regenerated lockfile is not meaningfully
reviewable, and the PRs are structurally release-inert: lockfiles sit in the CI
detect job's path-exclusion list, so a lockfile-only push has
root_changed=false and cannot publish or tag. rollback, replacement and
bump still fail closed to manual review.

Verification

renovate-config-validator --strict passes, but it does not gate this
change: it rejects a typo'd matcher key (matchUpdateTypesTYPO) while silently
accepting a bogus enum value inside matchUpdateTypes
(lockFileMaintenanceTYPO validates clean). So the change was verified against
the running Renovate 44.7.3's own code instead — applyPackageRules from
dist/util/package-rules, fed a synthetic config per update type:

updateType	before	after
lockFileMaintenance	false	true
patch	true	true
minor	true	true
major	false	false
rollback	false	false
bump	false	false
replacement	false	false

Exactly one cell flips. Two supporting facts from the same source:

• workers/repository/updates/flatten.js sets updateType on the
  lock-file-maintenance config and calls applyPackageRules on it twice, so a
  rule whose only matcher is matchUpdateTypes does apply to it.
• The two automerge: false supply-chain rules (git-cliff asset swap,
  tool-registry retag) both carry matchDepNames, which can never match a
  config that has no dep, so they cannot collide with this rule.

Effect on the 10 already-open PRs

They pick the new policy up on the next Renovate run even though the Monday
schedule window has closed: with a branch and a PR both already present and
updateNotScheduled at its default true,
update/branch/index.js logs "Branch + PR exists but is not scheduled -- will
update if necessary" and falls through to the automerge check rather than
returning not-scheduled.

Documented in cplieger/.kiro steering/ci-renovate.md.