ci: ignore mocha semver-major updates

[dhensby]

Holds mocha at 11.x so the package keeps testing the Node versions it claims to support.

Why

Mocha 12 declares engines: "^20.19.0 || >=22.12.0", and its CLI entrypoint uses import attributes:

// node_modules/mocha/lib/cli/cli.js:17
import packageJson from "../../package.json" with { type: "json" };
                                             ^^^^
SyntaxError: Unexpected token 'with'

That is a parse error on Node 16 and 18 — not a soft warning, and not something a flag works around.

Both versions are still first-class entries in the CI matrix ([16.x, 18.x, 20.x, 22.x, 24.x]), and the compiler targets @tsconfig/node16. So the package actively advertises support for them.

The options, and why this one

	Option	Verdict
1	Hold mocha at 11.x	✅ this PR — keeps the matrix honest, upgrade stays available as a deliberate future step
2	Take mocha 12, drop 16/18 from the matrix only	❌ leaves the package claiming support for runtimes it never exercises
3	Take mocha 12, hard-drop 16/18 with a major release	❌ disproportionate — mocha is a dev dependency; it should not dictate the public support floor

Option 2 is the tempting one and the worst: untested support is more dangerous than either honest position, because the breakage surfaces in a consumer's environment rather than in CI.

Why a config rule, not a comment

An @dependabot ignore this major version comment suppresses exactly one major. They accumulate, and a fresh PR lands with every subsequent release. A version-update:semver-major rule holds the whole line.

Revisiting

Deliberately reversible. When the support floor is raised, drop this rule and take mocha 12 in the same change — that keeps the engines bump, the matrix change and the tooling upgrade in one reviewable commit, which is exactly where that decision belongs.

Mirrors the existing @types/node rule added in #240, which holds the same support floor for the same reason.

Closes #253 once merged — Dependabot retires the superseded PR automatically.