Implement ILayoutEngine plugin loading

## Problem / goal

Implement `ILayoutEngine` plugin loading so third parties can add layout algorithms without modifying Bastion's own source, while structurally preventing a plugin from touching Win32.

## References

- `DESIGN.md` §3.9 (Extensibility paragraph) — two-tier extensibility: in-process `ILayoutEngine` plugins are pure code consuming `(tree, workArea, constraints, gaps)` and returning rects, structurally unable to touch Win32; everything else is out-of-process over the IPC schema.
- `DESIGN.md` §12 (v0.5 roadmap line).

## Acceptance criteria

- [ ] Third-party `ILayoutEngine` implementations can be loaded from a configured directory/assembly path without modifying Bastion's own source.
- [ ] A loaded plugin is structurally prevented from touching Win32 types (the same `Bastion.Layout` purity boundary applies — loading happens in a way that cannot hand the plugin an HWND or any `Bastion.Win32` type).
- [ ] A malformed/throwing plugin degrades to "layout unavailable, falls back to a built-in engine" rather than crashing `bastiond`.
- [ ] This satisfies AOT/trim constraints — state explicitly in the PR how plugin loading coexists with `PublishAot=true` on `Bastion.Daemon` (e.g. via a documented, trim-safe plugin-loading pattern) rather than silently reintroducing reflection-heavy dynamic loading.

Start with DESIGN.md §3.9 and §12, then trace ILayoutEngine and the Bastion.Layout purity boundary in Bastion.Daemon. Determine how configured plugin assemblies can coexist with PublishAot=true without unsafe reflection, and verify that malformed plugins fall back to a built-in engine without exposing Win32 types or crashing bastiond.

Written by the indexing model from the issue text.