[sharpSteff]

Closes #505

The bug

LayoutItem.SetDefaultBindings() seeded CanClose from the layout model with a plain assignment:

CanClose = LayoutElement.CanClose;   // stamps a LOCAL value

A local value outranks a Style setter in WPF's precedence order, so
<Setter Property="CanClose" Value="False"/> was silently discarded whenever the container style
arrived after the item already existed.

Which of the two happens first is decided by where the DataContext is assigned — which is exactly
why the issue reports it as a DataContext problem:

• code-behind (works): DocumentsSource resolves after LayoutItemContainerStyle(Selector) has
  been set, so the style setter applies to a fresh item and the trailing sync merely re-writes the
  same false.
• <Window.DataContext> in XAML (broken): the binding resolves during parsing, so the documents
  — and their LayoutItems — exist before the parser reaches the style property. The local true
  is already in place and the setter never takes effect. The close button stays visible.

The fix

One line in Controls/LayoutItem.cs — seed the value with SetCurrentValue instead:

SetCurrentValue(CanCloseProperty, LayoutElement.CanClose);

This keeps the model sync but leaves the local-value slot free, so a style setter applied later
still wins and still propagates back to the layout model through OnCanCloseChanged.

IsSelected, IsActive and LayoutAnchorableItem's Visibility sit on adjacent lines with the
same latent problem but are deliberately left as plain assignments: those are commonly bound
Mode=TwoWay in container styles (see source/MVVMTestApp/MainWindow.xaml), and SetCurrentValue
does not write back through a two-way binding, so converting them would quietly break model
write-back. Happy to revisit that separately if you'd prefer them changed too.

Tests

LayoutItemContainerStyle / LayoutItemContainerStyleSelector had no test coverage at all.