fix: split external dev dependencies into their own Renovate group

The `renovate/stability-days` status check is computed per branch, not per
package, so a single member still inside its minimum release age turns the
whole grouped branch yellow and blocks automerge. With every external
dependency in one group, that check is yellow most of the time.

Split dev dependencies out of `external fixes` and `external major` into
`external dev fixes` and `external dev major`. On helix-cli this halves the
group size (44 runtime vs 16 dev at the root manifest), so each group reaches
a fully-aged state far more often.

Uses `matchDepTypes` rather than package names, so the split reads npm's own
manifest sections and needs no maintenance as dependencies change. This is
Renovate's documented grouping idiom.

The two existing rules are left byte-for-byte unchanged. The new rules are
appended after them, so they override only `groupName` and inherit
`automerge`, `schedule` and `minimumReleaseAge` from the rule above. The
catch-all rules deliberately keep no `matchDepTypes`, so anything that is not
a devDependency -- runtime, optional and peer deps, npm `engines`, and every
non-npm manager such as github-actions or dockerfile -- keeps its grouping and
its 14-day minimum release age.

The 14-day window itself is unchanged.

Author: trieloff

default.json

@@ -88,6 +88,22 @@
       "schedule": ["after 2pm on Monday"],
       "minimumReleaseAge": "14 days"
     },
+    {
+      "description": "Split dev dependencies out of the two external groups above, so each group is smaller. The `renovate/stability-days` check is computed per branch, so any single member still inside its minimum release age holds the whole group back; smaller groups reach a fully-aged state more often. Split by depType rather than by package name so it needs no maintenance as dependencies change. These rules come after the two catch-all rules above and therefore override their `groupName`; the catch-alls deliberately keep no `matchDepTypes`, so anything that is not a devDependency -- runtime, optional and peer deps, npm `engines`, and every non-npm manager such as github-actions or dockerfile -- keeps its grouping and its 14-day minimum release age.",
+      "groupName": "external dev fixes",
+      "matchDepTypes": ["devDependencies"],
+      "matchUpdateTypes": ["patch", "pin", "digest", "minor"],
+      "matchPackagePatterns": ["^.+"],
+      "excludePackagePatterns": ["^@adobe/"]
+    },
+    {
+      "description": "Same dev/runtime split as above, for major updates.",
+      "groupName": "external dev major",
+      "matchDepTypes": ["devDependencies"],
+      "matchUpdateTypes": ["major"],
+      "matchPackagePatterns": ["^.+"],
+      "excludePackagePatterns": ["^@adobe/"]
+    },
     {
       "description": "Renovate cannot enforce a minimum release age on these update types, because they carry no usable release timestamp. Leaving them subject to `minimumReleaseAge` makes the branch-level `renovate/stability-days` check go permanently yellow, which silently blocks automerge forever. Mirrors the carve-outs in Renovate's own `security:minimumReleaseAge*` presets.",
       "matchUpdateTypes": [