[sharpSteff]

The manager learns about a toolbox when it registers it, which happens once it is loaded. A view model built by a dependency injection container is constructed long before that, so an IsOpen it set was decided while nobody was listening: the manager only applied IsOpenByDefault, and the value was dropped. Because a property that does not change raises no notification, the toolbox was then stuck - it already held true, so asking for true again did nothing and it could not be opened from the view model at all.

The same drift arose without any startup involvement. A zone shows one toolbox at a time, so opening one collapses its sibling, and that collapse never wrote back onto the sibling's toolbox. Two toolboxes with IsOpenByDefault in one zone reproduced the stuck state on the first frame.

• Replace OpenDefaultToolboxes with ApplyInitialToolboxState, which reads IsOpen as well as IsOpenByDefault and leaves what already shows alone, so running it again never collapses an open toolbox.
• Write the state back when a toolbox is collapsed to make room for a sibling, and when a detached window is brought forward instead of docked.
• Reconcile the toolboxes against the layout after a stored layout replaced the tree.
• Fold the view model driven open path into ToggleAnchorable rather than repeating it. The duplicate had drifted: it missed the detached window case, so setting IsOpen = true on a detached toolbox tried to dock it.
• Re-apply the state after a theme change, which rebuilds the bars and collapsed every open toolbox on the way.

IsOpenByDefault now seeds IsOpen, which from then on is the single answer to whether a toolbox is showing