chore(deps): group react + react-dom in Dependabot config

[os-zhuang]

Fixes #159

What

Adds an explicit react group to .github/dependabot.yml, alongside the existing objectstack group:

groups:
  objectstack:
    patterns:
      - "@objectstack/*"
  react:
    patterns:
      - "react"
      - "react-dom"

react-dom@X peer-requires react@^X. Dependabot currently files them as two separate PRs, and a lone react-dom PR always carries a peer requirement its sibling PR is holding — the two are not independently mergeable. Grouping makes them arrive as a single, actually-mergeable PR.

Why package names are enumerated, not pattern-matched

apps/docs/package.json also declares "lucide-react": "^1.16.0" — an unrelated icon library with its own currently-open Dependabot PR (#161, lucide-react 1.16.0 → 1.33.0). A pattern like react* or *react* would silently pull it into this group too, coupling icon-library updates to React's release cadence with nothing failing to signal it. The group lists react and react-dom as literal names for that reason.

@types/react / @types/react-dom are intentionally excluded

The issue flagged these as unmeasured. Measured now: they're already on different versions from each other (@types/react@^19.2.17, @types/react-dom@^19.2.3), so they already float independently of the runtime pair and of one another. More importantly, the coupling this issue exists to fix — an npm/pnpm-enforced peerDependencies requirement — exists between react and react-dom themselves; DefinitelyTyped's type-only packages don't carry that same enforced peer relationship to each other or to the runtime packages. Adding them would widen this group's blast radius without addressing a real merge-blocking coupling. Not included.

react-dom's exact pin: left as-is, reported rather than changed here

The pin ("react-dom": "19.2.7" vs "react": "^19.2.7") was introduced as a bounded workaround in #158, and grouping removes the reason it exists — reverting to a caret is the honest end state. I tested whether that revert is achievable without any pnpm-lock.yaml change (both specifiers already resolve to 19.2.7):

$ sed -i 's/"react-dom": "19.2.7"/"react-dom": "^19.2.7"/' apps/docs/package.json
$ pnpm install --lockfile-only
$ diff pnpm-lock.yaml.before pnpm-lock.yaml
39c39
<         specifier: 19.2.7
---
>         specifier: ^19.2.7

The resolved version: doesn't move (still 19.2.7(react@19.2.7)), but the specifier: field does — pnpm-lock.yaml is not byte-identical. Per this card's constraint (deploy-docs.yml fires a production deploy on every pnpm-lock.yaml push to main, so any lockfile diff here has a blast radius no required check covers), I reverted the experiment and left the pin as exact. This is a real, if small, follow-up: someone should either accept the one-line lockfile diff in its own PR, or decide the belt-and-braces state (group + pin) is fine to keep. Recommendation: take the caret revert as its own tiny PR — the diff is exactly the one line shown above, already verified.

Dependabot schema notes (verified against GitHub's docs, github/docs dependabot-options-reference.md)

• Two groups in one updates: block compose fine, and there's a defined precedence, not silent conflict: "If a dependency matches more than one rule, it's included in the first group that it matches." objectstack and react have disjoint pattern sets (@objectstack/* can never match a bare react/react-dom name), so there's no shadowing here regardless of declaration order — but the ordering rule is real and worth knowing for future groups added to this block.
• No exclude-patterns needed: that option only matters when a patterns entry is wildcard-shaped and needs carving back down; enumerating exact names sidesteps the whole class of shadowing/overlap questions.
• Grouping is the right (and only real) mechanism here — nothing newer in Dependabot's config surface targets peer-coupled packages specifically; groups + explicit patterns is what the docs offer for "these must land together."

What this would and wouldn't have caught, against the five PRs open today

PR	Package	Captured by the new react group?
#160	fumadocs-core	No — not react/react-dom
#161	lucide-react	No — the exact trap this PR avoids; a wildcard pattern would have wrongly caught it
#162	@opennextjs/cloudflare (dev)	No
#163	wrangler (dev)	No
#164	@types/negotiator (dev)	No

None of the five currently-open Dependabot PRs are for react or react-dom, so this change doesn't retroactively affect any of them — its effect is on the next time Dependabot opens PRs for these two packages, which is exactly the mergeable-pair problem this issue is about.

Verification honesty

No gate in this repo validates dependabot.yml — GitHub only evaluates it when Dependabot itself runs. "CI green" below does not cover this change; it only confirms the change didn't break anything else. What actually tests this change: the YAML parses (yaml.safe_load), the two groups are structurally distinct (no overlapping pattern strings, disjoint by construction), and the reasoning above against the five real open PRs.

$ pnpm turbo run build   → exit 0
$ pnpm turbo run test    → exit 0
$ node .github/scripts/check-locale-surface.mjs   → exit 0 (run from repo root)

---

Generated by Claude Code