ci: add a dependabot config, deliberately quiet

[PathGao]

There is no .github/dependabot.yml. Nothing in this repository notices that a
dependency has moved — you find out when it breaks, or when someone goes
looking.

The evidence, from this repository, this cycle

#463. build.yml pinned the WebKitGTK stack at =2.44.0-2. tauri build
bundled 2.44.0 into the AppImage, and 2.44.0 fails EGL initialization against
modern Mesa: EGL_BAD_PARAMETER, process exits, no window ever appears. First
reported in #182; still broken on the v2.7.0 release; traced and fixed by an
outside contributor. The application did not launch, on a whole class of Linux
systems, because a pin nobody was watching aged out from under it.

dompurify sat at 3.3.1 while 3.4.12 was current. It is the sanitizer between
rendered Markdown and the webview — the one dependency where "a version behind"
and "a security posture" are the same sentence. It was bumped by hand this cycle
and is now pinned exactly in both dependencies and overrides.

comrak sat at 0.18 — a 2023 release — until it went to 0.54 by hand this
cycle. That is the Markdown parser. Thirty-six minor versions of upstream
behaviour and fixes, arriving as one jump rather than as a stream anyone had the
chance to read.

There is a real check here already: npm audit on the complete lockfile in
test.yml (#308, #314). But it is a gate, not a notice. It only speaks when
somebody opens a pull request, and when it does speak it turns a new advisory
into a red X on whichever unrelated pull request happened to run next. Neither
npm audit nor anything else in the tree looks at Cargo or at the actions.

What this configures, and the noise it costs you

Three ecosystems, each monthly, each grouped behind patterns: ['*'] so
everything that moved arrives as one pull request:

ecosystem	manifest	expected volume
npm	package.json (root)	1/month, ceiling
cargo	src-tauri/Cargo.toml	1/month, ceiling
github-actions	.github/workflows/	rare — most months 0

At most three pull requests a month, realistically closer to two. The actions
number is low for a checkable reason: of the five actions in use
(actions/checkout@v4, actions/setup-node@v4, actions/upload-artifact@v4,
softprops/action-gh-release@v2, dtolnay/rust-toolchain@stable), four are
tracked by major tag and only move on a major release, and the fifth is tracked
by branch — @stable is not a version, so Dependabot has nothing to bump there
at all.

Weekly on all three, ungrouped, would have been the default-shaped choice and
would have produced something like a dozen pull requests a month. That is the
volume at which a dependency bot stops being read, and an unread bot is worse
than none — it trains you to close things unexamined.

Security updates are not on this schedule and are not in this file. They are
a repository setting (Settings → Advanced Security → Dependabot security
updates), they open their own pull requests as advisories land, and they are not
subject to open-pull-requests-limit. applies-to: version-updates on each
group is precisely the knob that keeps them out of the monthly batch, so a
sanitizer advisory still arrives on its own, immediately, rather than waiting for
the first of the month. I cannot turn that setting on — I have push and
triage here, not admin. If it is off, this file gives you the quiet monthly
cadence and none of the promptness, which is the half that matters least. Worth
checking before merging.

What this would not have caught — including #463 itself

I want to be plain about this, because "add Dependabot" invites the assumption
that the motivating bug is now covered. It is not.

The apt pins in build.yml are not a package ecosystem Dependabot supports.
libwebkit2gtk-4.1-0=2.44.0-2 lives inside a run: block, as an argument to
sudo apt-get install. There is no package-ecosystem for that. Dependabot
would not have opened a pull request, would not have flagged the pin as stale,
and would not have said anything at all while the AppImage was broken. #463
had to be found by a user and fixed by hand, and it would have had to be found
by a user and fixed by hand with this file merged. It is here as evidence for
the class of problem — an unattended dependency that quietly ages into a
user-facing break — not as something this config fixes.

Two smaller ones:

• overrides in package.json. dompurify is pinned in both
  dependencies and the overrides block. Dependabot updates the manifest's
  dependency sections; I am not confident it rewrites overrides, and I did not
  verify it against a live run. If it does not, the first npm group pull request
  will bump one and leave the other, and the two need reconciling by hand. Worth
  watching on the first one rather than assuming either way.
• Grouping trades reviewability for count. One patterns: ['*'] pull request
  can carry a major bump that breaks the build, and it blocks the whole batch
  when it does. I chose it anyway because your scarce resource is pull requests
  to read, not lines to read, and because test.yml and test_build.yml already
  build on three platforms — a bad group fails loudly rather than merging quietly.
  If it becomes a nuisance, the fix is an ignore entry for the offender (a
  monaco-editor major is the likely candidate) or splitting majors into their
  own group; both are additive edits to this file.

Schema

Written against the current
Dependabot options reference,
read for this change rather than recalled — the grouping options in particular
have moved, and applies-to is the part this config depends on.

Two current options I looked at and deliberately did not use:

• cooldown (default-days, semver-major-days, …), which holds a version
  back for a set period after release so a yanked or hot-fixed version is never
  picked up. Genuinely useful, and largely redundant against a monthly cadence —
  a month is already a longer cooling period than any value I would have set.
• labels. This repository has no dependencies label; Dependabot creates
  its own defaults. Adding a label list would be configuration that has to be
  kept in sync with the label set for no gain.

Verification

• The file parses, and every key is a real one. Parsed with the yaml package
  already in this lockfile and checked field by field against the options
  reference: top level is version + updates; each entry uses only documented
  keys; applies-to: version-updates resolves inside groups.<name>, not beside
  it. A dependabot.yml that GitHub rejects fails the way a malformed workflow
  fails — silently, by simply never running — so I parsed it rather than reading it.
• Manifest locations confirmed against the tree rather than assumed:
  git ls-tree -r origin/master gives exactly one package.json and exactly one
  Cargo.toml (src-tauri/Cargo.toml), hence directory: / and
  directory: /src-tauri.
• npm run check — 645 files, 0 errors. npm test — 692 pass, 0 fail. This
  change touches no source; that is a "nothing broke" baseline.
• Not verified: an actual Dependabot run. The config's real behaviour — what
  the first grouped pull request contains, whether it touches overrides —
  cannot be observed until it is merged onto the default branch. Everything above
  about volume is arithmetic over the manifests, not an observation.

Your call

This puts recurring pull requests in your queue every month for as long as it is
merged, and you are the one who has to read them. If the cadence is still too
much, quarterly is a one-word change and the rest of the file stands; if it is
too little, weekly likewise. And if you would rather have the alerts without
the pull requests, Dependabot security alerts alone is a repository setting and
needs no file at all — merging nothing is a legitimate outcome here.