Wire native undo into menus, toolbar, and command validation

The command surface was already almost entirely platform machinery —
this card proves it and pins it. Headless probes established that
NSWindow.validateMenuItem answers enablement AND rewrites the row title
from the delegate-supplied manager, so 'Undo Move 3 Cards' flows step
phrase to Edit menu with no code of ours; under the lock the rows dim
and keep their names, the correct reading of the-stack-survives. The
toolbar twins validate through validateUserInterfaceItem, which never
touches labels — 03's static-label exception proven rather than
asserted — and their specs' enablement abstention is pinned so nobody
later adds a second, disagreeing answer. The one link a headless run
cannot close is the nil-target key-window resolution itself: standard
responder-chain behavior with none of our code in it, left as the
manual check. Base-edition 'disabled without undo' scaffolding is
reworded away — every base board has undo now. New suites cover the
trash's two doors (delete-then-undo byte-identical to Put Back's
effect), position-preserving restore of a middle card, and the
capstone: five gestures forward, five presses back to the origin
board, five forward again, the menu phrase asserted after every press.

Claude-Session: https://claude.ai/code/session_01SR4XGjmBE16ZUYWpfFHXwY

Kanban/UI/Board/BoardToolbar.swift

@@ -34,10 +34,13 @@ extension NSToolbarItem.Identifier {
 ///
 /// The app ships no Undo/Redo rows of its own: those are the standard Edit-menu items, nil-target
 /// `undo:`/`redo:` resolved up the responder chain (`KanbanApp.menuCommands`). The toolbar items
-/// carry the same actions with the same nil target, so "the pair disabled on boards without undo …
-/// matching their menu items" (03) is not a predicate written here — it is the same validation, and
-/// on a base-edition board (no undo stack until m8 wires native undo) both are disabled for the same
-/// reason the menu rows are.
+/// carry the same actions with the same nil target, so "matching their menu items" (03) is not a
+/// predicate written here — it is literally the same validation. Both reach the board window, whose
+/// `windowWillReturnUndoManager` hands back the session's `BoardUndoManager`, and both therefore
+/// enable exactly when that board has a step to cross and no read-only lock stands
+/// (13-native-undo.md ▸ Rules). **Every base board has undo**, so there is no edition-shaped
+/// disablement to write: 03's parenthetical about boards without undo is 06's *git* substrate, which
+/// only Pro binds.
 ///
 /// Their labels are the design's one exception to the menu-title rule: `NSUndoManager` rewrites the
 /// *menu* titles as the stack changes ("Undo Move Card"), which a toolbar label does not track, so