chore(deps): consolidate eight Dependabot bumps into one change

[lamemustafa]

Replaces #336, #337, #338, #339, #340, #341, #342 and #343 with a single change, so the license regeneration and compatibility reseal happen once instead of eight times. Each of those PRs would individually have gone stale the moment any other landed.

Rust — src-tauri/Cargo.lock

crate	from	to
uuid	1.26.0	1.26.1
reqwest	0.13.4	0.13.5

reqwest pulls base64 0.23.1 alongside the existing 0.21.7/0.22.1 — expected.

Security check, done explicitly: reqwest is how rustls enters this tree, and #381 just patched rustls to 0.23.45 for RUSTSEC-2026-0285 (affected range 0.23.13–0.23.44). Verified before and after: rustls remains 0.23.45. A routine dependency bump silently walking that back into the vulnerable range was the specific risk here.

Frontend — package.json + pnpm-lock.yaml

package	from	to	resolved
react	^19.2.8	^19.3.0	19.3.0
react-dom	^19.2.8	^19.3.0	19.3.0
lucide-react	^1.41.0	^1.44.0	1.46.0
@types/react	^19.2.18	^19.3.0	—
@types/react-dom	^19.2.7	^19.3.0	—
vite	^8.2.2	^8.3.0	—

lucide-react resolves to 1.46.0 rather than 1.44.0 — inside the caret range, noted because the resolved version differs from the requested floor.

Deliberately excluded: jsdom

jsdom stays at ^28.1.0. Dependabot #343 proposed 30.0.1, whose engines is ^22.22.2 || ^24.15.0 || >=26.0.0 — this repo declares "node": ">=22.12 <25", so 30.0.1 excludes Node 22.12–22.22.1 and 24.0–24.14.

#348 holds this pending an owner decision and says explicitly that no successor PR should be created for it. Bundling it here would have overridden that silently. #348 stays open; vite from the same Dependabot group is carried because its engines (^20.19.0 || >=22.12.0) satisfies the current floor.

Worth noting for that decision: .node-version is already 24.18.0, so CI has been running well above the declared minimum — the contract and the practice already disagree.

GitHub Actions (SHA-pinned; SHA and version comment both updated)

action	from	to	occurrences
taiki-e/install-action	v2.87.5	v2.87.10	3 (ci.yml ×2, dependency-security.yml)
pnpm/action-setup	v6.0.10	v6.1.0	4 (ci.yml ×2, dependency-security.yml, release-mcpb-preview.yml)
actions/configure-pages	v5.0.0	v6.0.0	1 (deploy-install-page.yml)
actions/deploy-pages	v4.0.4	v5.0.1	1 (deploy-install-page.yml)

Label correction: the existing actions/deploy-pages pin was commented # v4.0.5, but SHA decdde0ac… is tag v4.0.4 — verified against the GitHub tags API. Dependabot #340's title said 4.0.4→5.0.1 while its own diff comment said v4.0.5 on both sides; both the version and the label are corrected here.

The two actions/* bumps are majors. They affect only the GitHub Pages install-page deploy, so the blast radius is that page rather than the product build.

Verification performed

• corepack pnpm run license:all → "Frontend license inventory matches 5 locked components" / "Rust license inventory matches 384 locked components".
• corepack pnpm test → all green: 147 node --test cases, 113 vitest cases across 8 files, 10 Playwright cases (chromium + webkit). A React 19.2→19.3 and Vite 8.2→8.3 bump is not free, so this was run rather than assumed.
• Compatibility surface resealed in the documented order. rehash-surface reported 5 changed entries; all five enumerated and accounted for as files actually edited: ci.yml, dependency-security.yml, package.json, pnpm-lock.yaml, src-tauri/Cargo.lock. Confirming pass reports 0. Neither JSON was hand-edited.

One change beyond the brief

THIRD_PARTY_LICENSES.txt (the frontend inventory) needed two header updates — lucide-react 1.41.0→1.46.0 and react/react-dom/scheduler 19.2.8/19.2.8/0.27.0→19.3.0/19.3.0/0.28.0. Unlike the Rust inventory, this file is hand-maintained with no generator, so license:all could not pass without it. Flagged rather than absorbed silently.

That absence of a frontend generator is itself worth fixing — it is the same manual-regeneration tax that issues #349/#350/#351 describe.

Not run

cargo check / cargo test / clippy were not run locally on the Rust side. CI's native checks are the verification for the two lockfile bumps; please don't read this as locally build-verified.

Closes #336, closes #337, closes #338, closes #339, closes #340, closes #341, closes #342, closes #343

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[lamemustafa]

Extended: Node floor raised to the Active LTS line, jsdom unblocked

This PR now also resolves the decision that #348 was holding.

file	before	after
.node-version	24.18.0	24.21.0
package.json engines.node	>=22.12 <25	>=24.15.0 <25
jsdom	^28.1.0 (held)	^30.0.1
README.md	"Node.js 22 or 24"	"Node.js 24 (>=24.15.0)"
docs/release-process.md	"supported 22 or 24 releases"	"supported 24.x releases (>=24.15.0)"

Verified against nodejs.org/dist/index.json rather than assumed: v24 "Krypton" is the Active LTS, latest 24.21.0 (2026-09-07). v22 "Jod" is the older LTS line; v26 is Current and not LTS.

The floor is 24.15.0 rather than 24.21.0 deliberately: 24.15.0 is jsdom 30's own minimum within the 24 line, so the declared contract and the dependency's real requirement now agree, without rejecting contributors on any earlier 24.x for no reason.

CONTRIBUTING.md and AGENTS.md state no Node version — nothing to change. All six node-version-file: .node-version references across the workflows read the file at runtime, so they pick up 24.21.0 with no edit.

Verification

corepack pnpm test — all green: 147 node cases, 113 vitest cases across the 8 jsdom-backed suites, 10 Playwright (chromium + webkit). jsdom 28→30 is a two-major jump, so those 8 suites were the actual risk and they pass.

corepack pnpm run license:all passes; THIRD_PARTY_LICENSES.txt needed no hand-editing against jsdom 30's changed dependency set.

Resealed: package.json and pnpm-lock.yaml pins updated, confirming rehash_surface_changed:0.

What was NOT verified — please read before merging

#348's acceptance asks for jsdom-backed tests at "the selected minimum and current supported Node versions". Only one Node is installed on the machine this ran on (v24.18.0), and no version manager (nvm/fnm/volta/asdf/n) is available, so:

• 24.15.0, the new declared floor, was not exercised. It is derived from jsdom's stated engines, not from a test run.
• 24.21.0, the new CI pin, was not exercised locally either. CI is the first place that actually runs it.

So the tested point is 24.18.0, which sits inside the new range but is neither boundary. If you want the floor genuinely proven before merge, that needs a version manager run at 24.15.0 and 24.21.0 explicitly. Flagging it rather than letting a declared range imply tested support.

Refs #348