feat(ui): add an accessible VS Code-parity Tree

[EhabY]

Summary

Adds a controlled, accessible Tree to @repo/ui that follows current VS Code workbench behavior and visuals.

• Flat, data-driven row projection with aria-activedescendant
• Independent focus and selection, including hidden selection behavior
• Single selection, cleared by Escape before the key returns to the host
• Arrow, Home, and End navigation, into and out of branches
• Single-click and double-click expansion modes, twistie isolated from selection
• Explorer styling, indent guides, row actions, high-contrast support, and Storybook coverage

Closes #1037

This is the first of three stacked PRs, kept to the behavior a tree needs to be
usable at all:

	Adds	Lines
this one	rows, ARIA, navigation, expansion, single selection	2,710
#1079	multi-select, type navigation, paging, sticky scroll	1,916
#1078	row and action-bar hovers	685

Architecture

flowchart LR
  accTitle: Tree architecture
  accDescr: Data and input flow through pure Tree modules into the React and DOM adapter.

  Props[Nodes and controlled props] --> Model[treeModel.ts]
  Events[Pointer and keyboard events] --> Policy[treePolicy.ts]
  Policy --> Commands[Tree commands]
  Model --> Transition[treeTransition.ts]
  Commands --> Transition
  Transition --> Adapter[useTreeAdapter.ts]
  Adapter --> Rows[Tree.tsx and TreeRow.tsx]

Loading

treeModel.ts, treePolicy.ts, and treeTransition.ts are pure. useTreeAdapter.ts is the thin React and DOM boundary, which is what lets the two PRs above stack on this one without reshaping it.

The container delegates pointer, focus, and key events, so a row is memoized
presentation with no handlers and no adapter of its own. The flat visible model
supports future windowing, but this Tree is not currently virtualized.

API surface, checked against native

Every prop maps to something VS Code has, so the component stays a parity layer rather than a superset:

Prop	Native counterpart
expandMode: "singleClick" | "doubleClick"	workbench.tree.expandMode, same values
variant="explorer"	the align-icons-and-twisties render mode
TreeNode.icon, .action	TreeItem.iconPath, the row action bar

TreeNode.className is the one non-native field, kept as the hook for per-row color or emphasis. Webviews receive no workbench.tree.* settings, so a consumer that wants to mirror them reads them in the extension host and passes them down.

Two things deliberately do not exist, because native does not have them:

• Disabled rows. TreeItem has no such field, and every aria-disabled in the workbench is an action item or a toggle, never a list row. Dim a row through className instead.
• Actions gated on focus. A row's action bar stays live on plain hover, as in the native list. inert blocks hit-testing rather than only tab order, so gating it left a visible button that took neither a hover nor a click.

Divergences from native, and why

• Modern UI by default. Webviews get no signal for workbench.experimental.modernUI, so the package picks the newer look and data-ui-style="stable" restores stable row geometry, focus behavior, and menu motion.
• Escape handling. Selection clears first, then the focus mark, and only then is the key left to the host, so an embedding webview can still use it.

Choices worth a second look

• useMemo on the model and memo on the row are explicit, not left to the React Compiler. Every memoized row compares against the row objects the model holds, and a consumer of this package may not compile it; without the useMemo the memoization silently stops paying off.
• posInSet and setSize live on the row. Flat rows have no group element, so each row declares its own set. A parent-to-count map would have to be threaded into every row render, including the rows the sticky-scroll PR renders outside the tree, which have no model.
• The hover rule keeps its :not(). .ui-tree-item:not([aria-selected="true"], .ui-tree-item--focused) > .ui-tree-item__row:hover is native's own .monaco-list-row:hover:not(.selected):not(.focused); dropping it paints hover over a focused row.

Diff composition

Measured against origin/main...HEAD with git diff --numstat:

Area	Added	Deleted
Production UI source	1,227	6
Automated tests and shared helpers	1,111	0
Stories and visual fixtures	240	1
Documentation	100	8
Build and workspace configuration	32	2
Total	2,710	17

Production source to automated test code is approximately 1.10:1.

Performance

Measured in jsdom with 5,020 expanded rows (20 branches of 250 leaves), median
of three runs: mount 724ms, twenty ArrowDown presses 423ms, so roughly 20ms
a keystroke. That is the cost of building 5,020 elements and comparing their
props; only the two rows whose state changed re-render. Remove memo from the
row and those same twenty presses take 4,746ms, because the React Compiler
memoizes a .map() as one unit and the focused id invalidates all of it.

The Tree is not virtualized. Virtualization, if it is ever needed, is a
windowed slice over the same projection.

Validation

• pnpm test:webview --reporter=dot: 41 files, 372 tests passed
• Focused Tree suite: 6 files, 54 tests passed
• pnpm typecheck, pnpm lint, pnpm format:check, pnpm storybook:ci
• Every component in packages/ui compiles under the React Compiler with no bailout, checked by running babel-plugin-react-compiler over the package: 47 files, no bailouts. TreeRow used to bail out silently by reading other props from its parameter defaults; AGENTS.md and the package README now record the rule.
• Row geometry, indent guides, and theme parity verified in Chrome against a running Storybook in all four captured themes

Implementation plan and decisions

1. Keep the model, input policy, and interaction transitions pure.
2. Keep React state, controlled callbacks, refs, event normalization, and DOM effects in one thin adapter.
3. Render a flat visible row projection while retaining complete hierarchy data for hidden focus and selection behavior.
4. Preserve VS Code selection, expansion, keyboard, accessibility, and visual behavior.
5. Delegate events from the container so rows stay memoizable, and keep the memoization explicit rather than compiler-dependent.
6. Document the architecture with a compact Mermaid diagram.
7. Split the component tests into focused core, row, and keyboard suites over one shared harness, and test the pure modules directly.
8. Validate behavior, type safety, formatting, linting, builds, Storybook, test counts, and measured interaction performance.

_{This pull request description was updated by Coder Agents on behalf of @EhabY.}