What happened?

A TreeView whose TreeViewNodeData nodes carry a ContentElement shows
blank rows — the per-node content (Button / TextBlock / CheckBox / …)
is never displayed. A ListView given the same element content renders it
correctly, so the defect is specific to TreeView.

Minimal self-verifying repro: https://github.com/ReneeGA2020/ReactorTreeViewContentBug

Steps to reproduce

// TreeView — per-node ContentElement (renders BLANK)
TreeView(new[]
{
    new TreeViewNodeData("n1") { ContentElement = Button("TreeView: I am a Button"), IsExpanded = true },
    new TreeViewNodeData("n2") { ContentElement = TextBlock("TreeView: I am a TextBlock") },
    new TreeViewNodeData("n3") { ContentElement = CheckBox(true, label: "TreeView: I am a CheckBox") },
})

// ListView — same element content (renders correctly)
ListView(
    Button("ListView: I am a Button"),
    TextBlock("ListView: I am a TextBlock"),
    CheckBox(true, label: "ListView: I am a CheckBox"))

dotnet build -c Debug -p:Platform=x64
.\bin\x64\Debug\net10.0-windows10.0.22621.0\win-x64\ReactorTreeViewContentBug.exe -- --check

Expected vs. actual

The bundled --check walks the live visual tree and detects each item by its
unique label text (robust because the TreeView's internal TreeViewList derives
from ListView):

[check] ListView element-item content rendered:  True  (expected True)
[check] TreeView ContentElement content rendered: False  (expected True)
[check] BUG: TreeView ContentElement not rendered — a ListView with the same element content does render.

Reactor version / commit

c14d172

Platform

x64

.NET SDK version

10/11

Windows version

Windows 11 10.0.26100.1

Windows App SDK version

2.0.1

Logs / stack trace

[check] ListView element-item content rendered:  True  (expected True)
[check] TreeView ContentElement content rendered: False  (expected True)
[check] BUG: TreeView ContentElement not rendered — a ListView with the same element content does render.

Confirmation

• I have searched existing issues and this isn't a duplicate.
• This bug reproduces against the current main branch (or I've noted otherwise above).