Implement the manual split-tree, master-stack, and monocle layout engines

## Problem / goal

Implement the three remaining layout engines named in DESIGN.md: manual split-tree (i3-style opt-in mode), master-stack, and monocle. `Bastion.Layout` currently has only the dwindle engine.

## References

- `DESIGN.md` §6 (Layout Engine) — "each algorithm owns its own structure": manual split tree = i3 semantics opt-in mode; master-stack; monocle — all producing rects from the same `(tree, workArea, constraints, gaps)` inputs as the dwindle engine.
- `src/Bastion.Layout/ILayoutEngine.cs` (the interface every engine implements).
- Depends on the v0.1 persistent-SplitTree issue — the manual split-tree engine is the most direct consumer of that data structure, exposing i3-style manual split commands instead of dwindle's automatic alternation.

## Acceptance criteria

- [ ] Three new `ILayoutEngine` implementations exist: manual split-tree (i3-style manual split-direction commands), master-stack, monocle.
- [ ] Each passes the same Tier 1 property tests as `DwindleLayoutEngine` (no-overlap, full-coverage, min-size respect, determinism) via the shared property-test generators (`docs/engineering/testing.md` §3) — parameterized/shared test code, not four independent copies, unless there's a concrete reason one engine's test needs to diverge (state the reason if so).
- [ ] A config option selects which engine a given workspace uses (mechanism can be minimal — a string key resolved to an `ILayoutEngine` instance is sufficient for this issue; the plugin-loading version of this is its own v0.5 issue).

Start with DESIGN.md §6 and src/Bastion.Layout/ILayoutEngine.cs, then review the v0.1 persistent-SplitTree issue and docs/engineering/testing.md §3. Implement the three engines and workspace selection, then run the shared Tier 1 property tests for no-overlap, full coverage, minimum-size respect, and determinism.

Written by the indexing model from the issue text.