chore(deps): sync the three upstream dependency commits

[IgorShevchik]

Ports 9c99bf16, 9d46fc7e and 20c1954d — a contiguous run, taken in one PR per §6 4b, because separating them would rewrite the lockfile three times over the same packages. Cursor moves to 20c1954d; one upstream commit remains in the queue (e791d302, fix(Select/SelectMenu): add responsive text size), which is a component change and gets its own PR.

9c99bf16 — not only versions

Renovate's title says dependencies; the commit carries a runtime fix that exists because of one of its own bumps:

+import { toRaw } from 'vue'
-export function validateSchema<T extends object>(state: T, schema: FormSchema<T>) {
+export function validateSchema<T extends object>(state: T, _schema: FormSchema<T>) {
+  const schema = toRaw(_schema)

Zod 4.5 resolves ~standard through a lazy getter that captures this. A schema held in reactive state arrives as a Vue proxy, so the getter reads the non-configurable _zod internals through it — violating the proxy invariant and throwing. Ported verbatim against an identical pre-image at form.ts:80.

Worth stating plainly: this fork was on zod ^4.4.3, where the bug does not bite. It goes live with the ^4.5.4 bump in the same commit, which is also taken — so the fix arrives with its trigger rather than speculatively.

Versions follow the delta rule (bump only where our pre-image matched upstream's). Left alone with reasons: nuxt-schema-org (ours ^6.2.1, a recorded dep-parity exception — any bump drags nuxt-site-config 4.2.3, which calls two functions absent from @nuxt/kit@4.5.2); packageManager (ours pnpm@11.20.0, upstream's pre-image is not ours); and packages this fork does not carry.

pnpm-workspace.yaml: one removal taken, one refused

Upstream deletes both its mdc override and its whole minimumReleaseAgeExclude. Decided separately, by measurement:

minimumReleaseAgeExclude — removed	Verified, not assumed: with the block gone, pnpm install still reports "Lockfile passes supply-chain policies (1794 entries)". @nuxtjs/mdc@0.23.1 is simply old enough now. Dropping a spent exception tightens the policy.
@nuxt/content>@nuxtjs/mdc — kept, against upstream	Upstream can drop it having moved to content 3.16.0 (cap ^0.23.1 vs 3.15's ^0.22.2). Tested here instead of inherited: remove it, reinstall, read the lockfile — two mdc versions appear, 0.22.2 alongside 0.23.1, exactly the failure the comment describes. The old copy comes from the root peer @nuxt/content: ^3.0.0, deliberately wide so consumers are not forced onto one minor, which resolves to 3.14.0.

Method note, because the first attempt got it wrong. Counting copies with find node_modules/.pnpm lies — the store keeps directories from earlier installs, and it showed a 0.22.2 the lockfile did not contain. The conclusion above was re-derived from pnpm-lock.yaml, which is the resolution.

9d46fc7e — tiptap, plus a companion upstream has no need for

25 declarations across five manifests move ^3.30.2 → ^3.30.5. Our pnpm-workspace.yaml also carries a '@tiptap/pm': ^3.30.2 override whose comment ends "Keep in step with the @tiptap/* family version in package.json" — this is the commit that triggers that instruction. Left behind it would still resolve, but the pin would no longer say what it means. Verified: the lockfile holds exactly one @tiptap/pm@3.30.5.

20c1954d — reka 2.10.4, and 1316 snapshot lines

What 2.10.4 changes was derived from upstream's own snapshot diff rather than its release notes, by matching each -/+ pair and extracting the differing substring. Three changes:

component	change
RadioGroup	aria-label="<value>" removed from the radio button
Stepper	the indicator <div> inside the trigger becomes a <span>
Select	aria-controls="reka-select-content-…" removed from the trigger

The RadioGroup one is a correction, not a loss, and that was worth establishing before accepting it. Each radio sits inside its <label data-slot="item">, which also holds the visible <span>Option 1</span> — an implicit association that already names it. While aria-label was present it won over that association, and what it carried was the item's value. A radio whose visible text read "Option 1" announced itself as "1". Removing it hands the name back to the visible text.

Our snapshots were regenerated and then checked rather than trusted, since -u rewrites a real regression as readily as an expected change. The same extraction against our own diff gives the same three deltas and nothing else — and one further check, because a per-line diff can miss a deletion that lands everywhere at once: the set of attribute names in each of the three files is identical before and after.

A correction to yesterday's guard

test/utils/sync-ledger.spec.ts, added in #515, asserted "no entry carries pending-merge". §6 step 4 requires them to: the entry is written in the same commit as the port, before its PR has a number or a squash SHA. It went red on the very next port — this one — and as written would have blocked the documented process rather than guarding it.

The real invariant is ordering. Reconciliation happens in sequence, so pending entries must form a suffix; one sitting behind a reconciled entry means a bookkeeping PR was skipped, and that is the failure that is otherwise invisible. Three mutations verified: a pending entry in the middle goes red, this PR's three-entry tail stays green, a fully reconciled ledger stays green.

Verification

dev:prepare · lint · typecheck · build (3.86 MB) · test — 340 files, 7694 passed, 6 skipped · test:module. pnpm install --frozen-lockfile passes against the committed lockfile.

---

Generated by Claude Code