chore(deps): bump @pierre/diffs to 1.2.12 (stage 1 of 2)

[backnotprop]

Why staged

This is stage 1 of a two stage @pierre/diffs upgrade. 1.2.12 was published 2026-06-29 and is safely aged per our 7 day supply chain posture. Stage 2 (next week, once aged) takes 1.3.x, which carries the @pierre/theme major and the hover pipeline visual rework; that one needs dedicated visual QA, so it is deliberately not in this PR.

What 1.2.9 to 1.2.12 delivers

• Focus no longer moves on line number click (1.2.12)
• Merge conflict actions remain available after resolving one conflict (1.2.12)
• shiki range widened to ^3 || ^4 (1.2.10); we still resolve shiki 3.23.0
• Misc fixes

Note: 1.2.9's npm tarball was historically broken (our #880 era). The fresh install check below specifically guards that failure mode for 1.2.12.

One audit correction

The pre-upgrade audit stated 1.2.9 to 1.2.12 carries no theme dependency change. The registry disagrees: @pierre/diffs@1.2.12 pins @pierre/theme@1.1.0 (was 1.0.3) and adds a new @pierre/theming@0.0.2 package. Both are transitive only; no workspace package depends on @pierre/theme directly, and our source has zero direct theme imports. This is a theme minor, not the 2.x major that stage 2 carries, but it does mean the rendered CSS is not byte identical, which raises the value of the manual visual QA below.

Lockfile diff, every changed line

• "@pierre/diffs": "1.2.8" to "1.2.12" in the six workspace dependency blocks (root, packages/ui, packages/server, packages/review-editor, apps/review, apps/pi-extension): the bump itself.
• @pierre/diffs resolution entry: new version, new integrity hash, and its dependency block now lists @pierre/theme 1.1.0, @pierre/theming 0.0.2, diff 9.0.0, and shiki/@shikijs/transformers at ^3 || ^4.
• @pierre/theme entry: 1.0.3 to 1.1.0 (transitive, pulled by diffs).
• @pierre/theming@0.0.2: new transitive entry (its peer deps resolve to already present packages).
• "@pierre/diffs/diff": diff@8.0.3 to diff@9.0.0: scoped override inside @pierre/diffs only. Our own top level diff stays ^8.0.4 and still resolves to 8.0.4.
• Workspace version resyncs: apps/opencode-plugin, apps/pi-extension, and packages/server 0.24.1 to 0.25.1, apps/vscode-extension 0.16.7 to 0.16.8. These are pre-existing drift on main: the release version bumps landed in the package.json files without a lockfile refresh, so any bun install on main today writes these same four lines. Verified by diffing HEAD:bun.lock against the package.json versions at HEAD.

Verification performed

Check	Result
bun run typecheck (all seven tsconfigs, after vendor.sh)	pass
Full bun test (3007 tests, 250 files)	pass (one run had a single failure in packages/server/review-workspace.test.ts semantic diff availability; it passes in isolation and the full suite reran fully green, consistent with the known server file timing flakes)
DOM_TESTS=1 isolated useFileBrowser.test.tsx	pass (6/6)
DOM_TESTS=1 CI DOM set (28 files from test.yml)	pass (163/163)
bun run --cwd apps/review build	pass, no warnings
bun run build:hook	pass
bun run build:opencode	pass
bun run build:pi	pass
Built HTML not committed	confirmed, all dist and copied plugin HTML paths are gitignored
Worker pool bundling (@pierre/diffs/worker/worker.js?worker&inline)	inline worker blob present in apps/review/dist/index.html (createObjectURL plus data URL script), build emitted no warnings
Installed tree	node_modules/@pierre/diffs is 1.2.12; exports map intact for our import surface (., ./react, ./ssr, ./worker/worker.js)
SSR parity (before vs after)	preloadFile output on three fixture files at 1.2.8 vs 1.2.12: prerendered HTML structure identical except tabindex="0" removed from the <pre> wrapper, which matches the 1.2.12 focus fix. The embedded data-core-css stylesheet changed: 1.2.12 ships it unminified (formatting and attribute quoting noise) plus real rule evolution consistent with the release notes (merge conflict actions, hover computed vars). No structural surprises.
Fresh install regression (#880 mode)	bun pm pack of apps/pi-extension, then npm install of the tarball in a scratch dir with a clean cache: resolves @pierre/diffs@1.2.12 from the registry, dist/ssr and dist/worker intact, and a Node runtime smoke of preloadFile from that install renders successfully
@pierre/theme still 1.0.3	no: 1.2.12 requires 1.1.0 transitively (see audit correction above); we have no direct dependency on it

Not verified here: manual visual QA checklist

Headless verification cannot observe rendering, and the theme 1.1.0 transitive bump means CSS did change. I am not claiming visual parity. Before merging, a human should check:

• 40+ file diff in all files view with fast scrolling
• Stage/unstage header chips
• File comment popover anchoring
• Hover a changed line at subtle/normal/strong intensity, in light and dark
• Guided Review on a large diff
• CodeFilePopout
• DiffHunkPreview
• Single file split and unified views with expand unchanged
• Search highlighting
• One session with VITE_PIERRE_VALIDATE_HEIGHTS=1

Stage 2 pointer

Next week, once 1.3.x has aged past the 7 day window: bump to 1.3.x, take the @pierre/theme major and the hover pipeline visual work, with full visual QA. Do not fast forward this PR to 1.3.x.

[backnotprop]

Adversarial review (at d2b5a526)

Verdict: merge as-is, after the human visual QA pass the PR correctly gates on. Every claim in the body reproduced independently.

Supply chain (the review's primary focus): clean, with the #880 mystery solved. @pierre/theming was never a squatted phantom: Pierre published diffs@1.2.9 at 02:17 UTC depending on theming@0.0.1, then published theming itself at 16:48 the same day. The 14.5-hour publish-order gap is issue #880. Verified genuine on five axes: byte-identical six-account maintainer sets across all three @pierre packages, first-party source in the Pierre monorepo with shipped sourcemaps matching that layout, npm audit signatures verified on all 212 packages, contents inspected (zero eval/child_process/fs/network/URLs, pure theme computation), and zero install scripts in all three, which is stricter than the packages we ship today. All three aged 35 to 38 days, well past the 7-day posture. The theme 1.0.3 to 1.1.0 minor changes not one color value in the existing themes; it adds four colorblind-accessibility variants and a displayName field.

Verification re-run independently: 2793 pass / 0 fail, DOM set 163/163, all four builds green in order, lockfile byte-stable after install with zero unexplained lines (the four workspace resync lines verified as genuinely pre-existing drift at the base commit), root diff isolated at 8.0.4 from the scoped 9.0.0, shiki unchanged at 3.23.0. The #880 fresh-install check passed from a clean cache with preloadFile executing under plain Node from the installed tarball. Runtime spot-check was real: system Chrome over CDP against a live review server on both builds showed identical DOM (759 elements, same line counts) with zero console errors; the only delta is the documented tabindex removal, verified as an accessibility improvement (the <pre> was never the scroll container, so the old attribute was one dead tab stop per file).

Findings, all low or informational:

1. Built bundles grow ~230KB (+1.1 to 1.3 percent), undisclosed and misattributable: the driver is @pierre/theme@1.1.0's four new colorblind themes entering the bundle, not the unminified CSS.
2. Those four colorblind themes are bundled but unreachable: SHIKI_THEME_MAP has no entries for them, so we ship accessibility themes users cannot select. The cost is already paid; exposing them in the theme picker is a cheap follow-up.
3. The theme name field rename ("Pierre Dark" to "pierre-dark") inside a minor is undisclosed; harmless here since our lookup already uses kebab names.
4. Stage-2 note: bunfig.toml's age-gate excludes only @pierre/diffs, not the theme packages; a future same-day Pierre release train would block on the gate. Pre-emptively adding both to the excludes list avoids that.
5. @pierre/theming never reaches the browser bundle (fully tree-shaken, install-time only).

The PR body's honesty held up under audit: performed vs deferred verification cleanly separated, the audit correction prominent, and the manual QA checklist complete against all six audit items.