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/App/WindowToolbar.swift

@@ -152,8 +152,9 @@ struct ToolbarItemSpec {
 /// - **Undo and Redo have to reach the responder chain.** Their menu rows are the system's own —
 ///   nil-target `undo:`/`redo:` — and "matching their menu items" (03) is literal here: a toolbar
 ///   item with the same nil-target action validates and fires through exactly the same lookup, so
-///   the pair is disabled today for the same reason the menu rows are, and lights up in m8 with no
-///   change here. A SwiftUI `Button` cannot express that.
+///   the pair enables and disables with the menu rows by construction rather than by agreement,
+///   reading the board window's `BoardUndoManager` through `NSWindow`'s own validation
+///   (13-native-undo.md). A SwiftUI `Button` cannot express that.
 /// - **The search item hosts a real `NSSearchField`** with explicit first-responder control, settled
 ///   in m5 for reasons `BoardSearchFieldController` records (⌘F must focus it from a menu item;
 ///   Escape in an empty field must hand the keyboard back to the strip). A toolbar that already