Document deferred renderer content lifecycle

[wieslawsoltes]

Summary

• explain that direct XAML content inside Document and Tool is deferred template content
• document why parent-window FindControl calls cannot initialize nested renderer controls from InitializeComponent()
• provide an MVVM-safe custom-control/attached-behavior lifecycle pattern
• document direct renderer hosting and explicit stretch alignment when a ContentControl wrapper is required
• add the same diagnosis to the FAQ

Root cause

The ActiViz RenderWindowControl is an OpenGlControlBase. In the issue reproduction, the VTK renderer setup depends on this call immediately after loading the parent window:

this.Find<RenderWindowControl>("VTKControl")

Dock compiles direct Document.Content XAML as deferred template content. A focused runtime check against the compiled DockXamlSample confirmed that, immediately after InitializeComponent(), the active document content has not been materialized and the parent view has no descendant content controls. The lookup therefore returns null, the attachment handler is never registered, and VTK displays an uninitialized blank surface.

Changing Dock to instantiate all document content eagerly would regress the intentional deferred/recycling architecture. The correct integration boundary is the renderer content's own attach/detach lifecycle, owned by a focused control, behavior, or service rather than parent-window code-behind.

Validation

• focused runtime inspection of compiled direct-document XAML
• isolated conceptual DocFX build: 0 errors, 1 existing api/toc.yml warning
• git diff --check

The repository-wide check-docs.sh reaches and renders all conceptual files, but currently exits nonzero during unrelated API extraction because DocFX cannot load the newer ReactiveUI source generator (existing partial-property errors).

Fixes #1090