one react-resizable-panels, and honest metadata for the peers

Two dependency problems, and only one of them was real.

── Real: two majors of the same library ──

The root asked for `react-resizable-panels@^4.0.15` (4.6.5) while
`src/workspaces/components` asked for `^2.1.7` (2.1.9). The workspace code targets 2.x,
whose API differs — v4 has no `PanelGroup` export, no `order` prop and no `ref` on
`Panel` — so a file that resolved the root's copy failed to typecheck in a way that
read like a broken extraction.

Nothing imported the root's version. It was vestigial, and removing it collapses the
repository to one: every importer now resolves 2.1.9 and the lockfile has zero v4
entries.

── Not real: the second React ──

Declaring react/react-dom in the package created
`src/workspaces/workspaces/node_modules/react`, which looks exactly like the
duplicate-instance bug that silently breaks hooks. It is not one. Both locations resolve
to the SAME file in bun's store — the local entry is a symlink — which I established by
resolving the specifier from each place instead of reading directory names, having
already reported it as a hazard on the strength of an `ls`.

Declared as optional peers regardless: that is the right metadata for a consumer, and it
stops bun installing peers it does not need to.

Notes corrected to match, since the wrong version of that story was written down.

tsgo clean, package 114/114, full suite 950 pass / 7 fail unchanged, frontend builds.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

WORKSPACES-NOTES.md

@@ -38,17 +38,22 @@ nothing.
 
 ## Two traps, both worth knowing before touching dependencies
 
-**A second React.** Declaring `react`/`react-dom` in the package produced a second copy under
-`src/workspaces/workspaces/node_modules`. Two React instances break hooks at runtime and are invisible
-until something renders. While this lives in the monorepo the package declares almost nothing and inherits
-the root's; publishing standalone means declaring them as peers, aligned with the host.
+**A second React — which turned out not to be one.** Declaring `react`/`react-dom` created
+`src/workspaces/workspaces/node_modules/react`, and a directory of that name looks exactly like the
+duplicate-instance bug that breaks hooks. It was not: both locations RESOLVE to the same file in bun's
+store (`.bun/react@19.2.4/…/react/index.js`), because the local entry is a symlink. Checked by resolving
+the specifier from both places rather than by reading directory names.
 
-**Two versions of `react-resizable-panels`.** The root asks for `^4.0.15` (4.6.5); `src/workspaces/components`
-asks for `^2.1.7` (2.1.9). This code was written against 2.x, whose API differs — v4 has no `PanelGroup`
-export, no `order` prop, no `ref` on `Panel`. Inheriting the root's resolution produced dozens of type
-errors that read like a broken extraction and were a version mismatch. The package pins `^2.1.7`.
+They are declared as `peerDependencies` with `peerDependenciesMeta.optional` anyway — correct metadata for
+a consumer, and it keeps bun from installing peers it does not need to.
 
-Worth resolving properly at some point: one repository, two majors of the same library.
+**Two versions of `react-resizable-panels` — real, and now fixed.** The root asked for `^4.0.15` (4.6.5)
+while `src/workspaces/components` asked for `^2.1.7` (2.1.9), and this code targets 2.x, whose API differs
+(v4 has no `PanelGroup` export, no `order` prop, no `ref` on `Panel`). Inheriting the root's resolution
+produced a screenful of type errors that read like a broken extraction.
+
+Nothing imported the root's copy — it was vestigial. Removed, so the repository now carries one version and
+the lockfile has zero v4 entries.
 
 ## Open