Refactor VTreeview on top of v0's Treeview

Replace VList's nested.ts and keyboard navigation control with v0's createNested + useRovingFocus, while keeping VTreeview's data-driven, styled public API.

v0 gaps to close first

Genuine blockers v0 must address (or we shim) before migrating:

• Selection strategies. v0's selection is a closed enum 'cascade' | 'independent' | 'leaf' with no custom hook. It covers classic (≈ cascade), independent, leaf — but not single-leaf/single-independent, not trunk/branch (these are classic with a different out-transform: trunk collapses fully-selected subtrees to the ancestor id, branch emits parents + leaves), and not custom SelectStrategy objects/factories. v3 takes a full select/in/out strategy; v0 has no equivalent injection point.
• Active strategies. v0 active: 'single' | 'multiple' vs VTreeview's single-leaf / leaf / independent / single-independent.
• Focusable content inside a tree item. v0's roving model makes only the row tabbable; nested interactive controls (buttons/links/inputs within a node) can't be reached by keyboard (reproducible on a v0 demo). Needs a secondary-navigation story before parity.

What stays in the Vuetify (by design)

• Data-driven rendering — items[] recursion + normalization (itemTitle/itemValue/itemChildren/itemProps, returnObject). v0 is compositional (<Treeview.Item> self-registers).
• Feature surface — search/filter, lazy loadChildren, no-data, openOnClick, separateRoots, hideActions, loading icons.
• Styling & slots — theming, density, variants, lines, slim, indent-lines (+ color/opacity), and the full slot API (prepend/append/title/subtitle/header/footer/divider/subheader/item/toggle).

What v0 gives us

Cleaner state primitives: reveal, enroll, mandatory, expandAll/collapseAll, selectAll, mixed/indeterminate, and ready-made TreeviewCheckbox / TreeviewSelectAll / TreeviewIndicator / TreeviewCue to replace ad-hoc selection plumbing. Roving focus driven directly (no VList container-tabindex conflict).

Work breakdown

1. Swap nested state to v0 createNested behind the existing renderer; keep VList styling.
2. Build the data → createNested registration in the recursive renderer.
3. Drive useRovingFocus from registered visible nodes; drop VList's keyboard/focus path.
4. Map selection/active strategies (compat shim or documented break).
5. Wire the styles & slots (prepend/append/title/subtitle/header/footer/divider/subheader/item/toggle).

Open question

Performance:

• VTreeview introduced items-registration="props" to avoid waiting for individual items mount/unmount lifecycle hooks and update the internal registry. It also makes it easier for VTreeview to potentially adopt virtual rendering in the future. We have to make sure it does not conflict with v0's implementation so we don't have to fight against it.

Is detaching VTreeview from VList viable in v5.0? Two targets:

• Engine-only (recommended short-term): v0 createNested + useRovingFocus underneath, VList kept as the visual shell. Far less disruptive. Preserves theming/slots for free.
• Full detachment: drop VList entirely, render/restyle v0's Atom output. Cleaner long-term and aligns with the framework-wide v0 rebuild, but re-implements all styling and the slot API — high parity risk.

Start by reading VList's nested.ts and its current keyboard navigation control, then compare them with v0's createNested and useRovingFocus. Trace the recursive renderer and existing selection and active-strategy handling before deciding how the listed v0 gaps are addressed. Done means VTreeview uses the new primitives while preserving its data-driven API, feature surface, styling, and slots.