fix: support nested StaticRender objects and optimize StaticRender API to ensure elements are really removed from the DOM.

[jacob314]

I tried multiple ways to optimize this and this one appears to be have been the most robust while performant.

I was also tempted to create a version that aligned a bit more when Ink's existing rendering support
but performance was poor when I tried to implement that way. I'm not exactly clear why it didn't work well but performance
was bad using the nestedStatic example to test performance. Starting up that example took multiple seconds while it is
basically instant with this approach.

Nested static items isn't a truly crucial feature but is a good test to make sure the static rendering is robust.

The most useful part of this change is switching so we fully evict statically rendered items from the virtual DOM. We weren't
doing enough of that previously resulting in performance struggles seen in GeminiCLI handling a DOM with a large number of statically rendered elements.

Moved StaticRender's layout evaluation to prepareYogaTree inside ink.tsx. This avoids repeatedly evaluating static subtrees during the main layout loop, treating nested and cached StaticRender components as efficient, fixed-size leaf nodes.

This fixes an issue where nested scrollable regions with overflowToBackbuffer=true would not render their newly revealed lines into the backbuffer because the root region artificially clipped the rendering canvas to the terminal height. By passing overrideHeight and isExpanded=true to the root region composeNode call during getLinesForScroll, the scrollable region receives the expanded context and correctly renders its off-screen lines, which are then successfully captured and written to the terminal history.

Tests to reproduce issues.

[jacob314]

this was no longer needed

[jacob314]

Overall, this is an excellent PR. Evaluating the layout for the static subtree inside prepareYogaTree and treating it as a fixed-size leaf node in the main layout loop is a fantastic optimization. Fully evicting statically rendered items from the virtual DOM via the isRendered state is an elegant way to reduce memory overhead and significantly improves performance.

Here are a few points to consider:

1. Breaking API Change

Changing children from ReactNode to () => ReactNode on <StaticRender> is a breaking API change.

• If you intend for this to be a breaking change, please consider appending a ! to the commit type in the PR title (e.g., fix!: support nested StaticRender objects...) or adding a BREAKING CHANGE: footer to the commit message to adhere strictly to Conventional Commits.
• Alternative Backward Compatibility: You could support both patterns to avoid breaking existing code, while still encouraging the new pattern for performance:

  export type Props = {
      readonly children: ReactNode | (() => ReactNode);
      // ...
  };
  // ...
  {isRendered ? null : (typeof children === 'function' ? children() : children)}

2. Potential Memory Leak in Region.node

The cached Region object retains a reference to the original DOM node (rootRegion.node). While the isRendered state successfully drops the React elements, just ensure that Region.node isn't inadvertently keeping a detached DOM tree in memory. Since the ink-static-render DOM element itself remains mounted, this is likely fine, but worth a quick double-check.

3. Excellent isExpanded Propagation

The logic introduced in composeNode to propagate the isExpanded state via inExpandedContext && Boolean(childRegion?.overflowToBackbuffer) is robust. It correctly ensures that only the specific scrollable regions with overflowToBackbuffer activated are expanded and captured for terminal history.

Great work on this! The tests and snapshots are looking solid and correctly follow the repository's testing standards (using SVG snapshots and headless xterm where appropriate).