chore(ci): enable Dependabot security updates so advisories stop breaking unrelated PRs' audit gate

[olivrg]

Problem

CI runs pnpm audit --audit-level=high, which hard-fails the moment any new high advisory is published against our dependency tree. But our only proactive dependency automation (.github/dependabot.yml) does weekly version updates only — it does not enable Dependabot security updates. So a high advisory published between weekly runs lands in CI and breaks whatever PR happens to be in flight, even when that PR is unrelated to the vulnerable package.

This has now happened three times, each handled reactively:

• esbuild GHSA-gv7w-rqvm-qjhr → audit ignore added (chore(security): ignore dev-only esbuild advisory GHSA-gv7w-rqvm-qjhr #63; drop tracked by chore(deps): upgrade vite so esbuild ≥0.28.1, then drop the GHSA-gv7w-rqvm-qjhr audit ignore #64)
• form-data + vite GHSA-fx2h-pf6j-xcff → override + dev-only ignore (chore(security): patch form-data, ignore dev-only vite advisory #68)
• hono GHSA-88fw-hqm2-52qc + undici GHSA-vmh5-mc38-953g → real upgrades (chore/audit-hono-undici)

Each time it blocks an in-flight feature PR (most recently the #11 Part A PR) on a vulnerability that has nothing to do with the change.

Root cause

1. Dependabot security updates are not enabled (a repo setting, not represented in dependabot.yml). Advisories only get picked up on the weekly version cadence, if at all.
2. The audit gate is correctly strict (fail-closed on highs), so the mismatch between "strict, instant gate" and "weekly, version-only updates" is structural — not bad luck.

Proposed fix

1. Enable Dependabot security updates (Settings → Code security → "Dependabot security updates"). Primary lever: auto-opens advisory PRs within ~hours of publication instead of the weekly window, so highs get patched before they break unrelated CI.
2. (Optional) Tune .github/dependabot.yml — e.g. a security-focused group and/or a tighter cadence — so advisory PRs land grouped and fast.
3. (Optional, policy) Decide and document how dev-only transitive advisories are handled (e.g. jsdom > undici, a test-env dep not shipped to users): patch-via-overrides (current approach) vs. a documented, time-boxed ignore. Codify the convention so future cases are consistent rather than ad hoc.

Acceptance criteria

• Dependabot security updates enabled on the repo.
• A newly-published high advisory results in an automatic Dependabot PR (verified once observed), not a surprise CI failure on an unrelated branch.
• The dev-only-transitive vs. shipped-dependency handling convention is written down (CONTRIBUTING or SECURITY).

Related

• chore(deps): upgrade vite so esbuild ≥0.28.1, then drop the GHSA-gv7w-rqvm-qjhr audit ignore #64 — drop the esbuild/vite audit ignore (same "stop band-aiding the gate" theme; can be closed alongside once vite is upgraded).
• Reactive precedents: chore(security): ignore dev-only esbuild advisory GHSA-gv7w-rqvm-qjhr #63, chore(security): patch form-data, ignore dev-only vite advisory #68, and chore/audit-hono-undici.