feat: allow nesting primitives inside containers in the builder

[DCCA]

Phase C of three on making Sandy usable as a daily design-system tool, after #26 (correctness) and #27 (the library).

The ceiling

A composite could only ever be a flat stack of primitives. builder-node-tree.tsx carried the comment "display only - nested operations not supported", and it was accurate:

• handleAddPrimitive always appended to the top-level nodes array, so nothing could go inside a container
• move, delete and the selection lookup all searched only that array, so a nested node could not be selected, reordered, deleted, or have its properties edited
• the tree rendered children but hid every action button on them

A designer could add a container, watch it render as an empty box, and never put anything in it. That rules out most real components - a card is a container with a heading and a body inside it.

What was already there

The limitation was only in the builder UI. Everything underneath already supported nesting:

• PrimitiveNode has children; ContainerRenderer renders them
• applyBindings / setNestedValue walk arbitrary paths, so a binding can target [0, "children", 1, "props", "text"]
• getBindableTargets already recursed into children, so the binding picker would have offered nested targets the moment any existed

So this adds no data model change, no migration, and no new persistence concern.

Design

Tree manipulation moves into pure immutable helpers in lib/composite/tree.ts - findNode, insertNode, removeNode, moveNode, updateNodeProps, depthOf. Keeping them pure makes the recursive cases testable without rendering anything, and collapses each builder handler to a single call.

Two decisions worth naming:

Where a new primitive lands. Inside the selected container when there is room, otherwise at the top level. The palette states which - "into selected container" / "at top level" - because the alternative is the user clicking and finding out. Selecting a non-container retargets it back.

How deep it goes. MAX_NEST_DEPTH is 2, matching the renderer's MAX_DEPTH. A node the user can build but the renderer refuses to draw is worse than one they cannot build, so only containers shallower than the ceiling are offered as a target. A test asserts the two constants agree, so moving one without the other fails.

moveNode reorders within a node's own sibling list only. Dragging across parents is a different interaction and is not attempted here.

Verification

• 299 unit tests (up from 277), 23 e2e (up from 19), typecheck, lint, format, build - all green
• 22 unit cases cover each helper against a two-level fixture: inserting at each level, refusing to nest into a non-container, removing a container with its children, reordering without escaping the parent, no-ops at boundaries, and immutability of the input
• E2E asserts the persisted definition after saving a nested component, so a flattened stack fails even if the UI looks right

Spec: docs/superpowers/specs/2026-07-18-nested-containers-design.md