chore(deps): drop the prosemirror pins, gate dedupe in CI

[christianhuening]

WP-8, the follow-up to the Tiptap 3 migration (#18). Removes the three exact
prosemirror-* overrides and replaces the Renovate rule that documented them.

Why the pins can go

They existed to deduplicate the ProseMirror core that @tiptap/pm and
y-prosemirror both pulled in. y-prosemirror is gone — @tiptap/y-tiptap
replaced it in #18, and it declares prosemirror-* as peer dependencies,
so it resolves to the consumer's copy and structurally cannot introduce a
second one.

Why they had to go

@tiptap/pm@3.31.3 declares prosemirror-model ^1.25.11 and
prosemirror-view ^1.42.3. The overrides held the tree at 1.25.7 and
1.41.8 — below both. pnpm overrides bypass range checks silently, so
this installed without a warning.

package	was	now	@tiptap/pm wants
prosemirror-model	1.25.7	1.25.11	^1.25.11
prosemirror-view	1.41.8	1.42.3	^1.42.3
prosemirror-state	1.4.4	1.4.4	^1.4.4

prosemirror-view 1.42.3 also carries an XSS fix in clipboard handling —
attribute validators were not run on attributes arriving via slice context.
No advisory was ever filed for it (OSV returns nothing for 1.41.8), so no
scanner would have surfaced it. knot was not reachable through it: Tiptap
only sets spec.validate when an extension declares one, and knot declares
none. Being on the patched release closes the exposure the moment that stops
being true.

a5c7042 introduced these pins blaming prosemirror-view 1.42 for a
history-restore failure, and ccf5dbd retracted that. This PR deletes the
last in-tree record of the exchange, so for the record:
e2e/flows/history.spec.ts is the test that motivated the pin, and it passes
on 1.42.3.

Why CI gains pnpm dedupe --check

Not belt-and-braces. While preparing this the tree was genuinely split for one
run — @tiptap/pm linked prosemirror-view@1.41.8 while @tiptap/y-tiptap
linked 1.42.3 — and tsc, eslint and all 153 unit tests passed anyway.
The old override comment claimed tsc would catch duplication with a wall of
"not assignable" errors. It does not: TypeScript is structural and the two
Node classes match.

Nothing else in CI looks at resolution, and lockFileMaintenance runs
pnpm update and automerges itself once green — so an automated lockfile
refresh could re-split the editor core unobserved. A split tree is silent by
construction: two ySyncPluginKey objects (y-sync$ and y-sync$1),
getState() returns undefined, and every comment anchor resolves to null
with nothing thrown. --check fails only when duplication is avoidable,
which is exactly the condition worth failing on.

Note for reviewers: plain pnpm install after removing the overrides leaves a
stale split tree; pnpm dedupe fixes the lockfile but does not relink
node_modules. pnpm install --frozen-lockfile (what CI does) produces the
correct tree. If you pull this branch, reinstall from the lockfile.

Renovate

The prosemirror-* rule is dead config now — Renovate does not raise PRs for
transitive npm deps outside lockFileMaintenance. Replaced with a rule
grouping @tiptap/y-tiptap into the tiptap group: it is published from
ueberdosis/y-tiptap, a different repo from ueberdosis/tiptap, so the
monorepo preset does not group it and it would otherwise be bumped in its own
PR without the tiptap version it has to work against.

Verification

• tsc --noEmit, eslint --max-warnings 0, 153/153 unit tests
• 18/18 editor-critical e2e specs (history, comment-anchors, collab,
  two-users-converge, markdown round-trip, excalidraw, mermaid, upload-image)
• Full suite on a freshly restarted stack: 60/63. tree-reorder "nest" is
  the known macOS-only dnd-kit failure that passes in CI; ws-reconnect
  cannot reach the toxiproxy admin API on this machine; comment-anchors:100
  timed out waiting for the add-comment float — upstream of any anchor logic,
  and the two sibling tests driving the identical helper and asserting on the
  resolved highlight both passed in the same run. All three pass in isolation.

Unrelated, worth filing separately

The collab room leaks a Postgres backend in idle in transaction holding
SELECT seq, doc_id, update_bytes, by_user_id, created_at FROM doc_updates
(knot-storage/src/updates_store.rs:107, UpdatesStore::since). Captured
mid-run: one such backend 2m37s old with four UPDATE sessions SET last_seen_at blocked behind it for the identical duration. Enough of them and
e2e/support/reset.ts can no longer take its table locks and the suite fails
in ways that look like editor bugs. since() uses no explicit transaction, so
the likely path is future cancellation — Registry::acquire → Room::spawn
awaits the hydrating since() inside the WS request future, which axum drops
when a client disconnects mid-upgrade, orphaning the sqlx connection
mid-protocol. Not touched here.

🤖 Generated with Claude Code