ci: group action updates so a split upgrade cannot break ci

[AndresSaa]

Follow-up to #46, which grouped the npm ecosystem. The github-actions block had no groups key at all — and it is the one where the omission actually breaks something.

What went wrong without it

One codeql-action upgrade, 4.37.4 → 4.37.6, arrived as three pull requests (#49, #50, #51), one per action path. Two were red by construction:

##[error]Loaded a configuration file for version '4.37.4', but running version '4.37.6'

init and analyze ship from the same commit, and the action refuses to run when they disagree. Bumping either half alone fails; merging them in sequence would have left main carrying a broken CodeQL job between the two merges. #52 repairs that instance by moving all three pins in one commit — this pull request stops it happening again.

Worth stating the difference from #46: on the npm side an ungrouped security update is noise. Here it is a failure. Same fix, higher stakes.

The change

groups:
  actions:
    applies-to: version-updates
    patterns: ["*"]
  actions-security:
    applies-to: security-updates
    patterns: ["*"]

Both applies-to values for the same reason as #46 — the default covers version updates only, so security advisories would still bypass grouping. A catch-all is right here: this repository uses a handful of first-party actions, and the failure mode is upgrades arriving split, never upgrades arriving together.

How it was tested

ajv vs. SchemaStore dependabot-2.0.json → VALID: true
npm -> dev-dependencies / security-advisories
github-actions -> actions / actions-security
npm run lint → clean

Same caveat as #46: GitHub parses dependabot.yml only from the default branch, so no check on this pull request validates it. Schema validation is the strongest pre-merge proof; after merge, Insights → Dependency graph → Dependabot reports a config error if one exists.

Contract impact

None. Repository automation only.