Implement the hybrid clipboard with deferred cut

⌘X/⌘C/⌘V for cards and lanes per 04-interactions.md § Clipboard:

- ClipboardStore stages full folder snapshots eagerly at the gesture into
  Application Support (at most the current copy; sweep at launch and on
  each copy purges what the pasteboard no longer references; a copy made
  before quitting pastes whole after restart) and writes the pasteboard a
  JSON manifest — every entry embedding its index.md, lane entries their
  cards' too — plus plain-text titles.
- Cut is Finder-style deferred: items dim in place off pendingCut, void on
  pasteboard takeover (changeCount, no timers), source-board close, or
  per-item external tombstoning; the first armed paste moves the surviving
  originals whole (tombstoned interior cards land in the destination's
  trash), a second paste materializes copies from staging.
- Paste anchors by the shared flatten-order rule (NewCardTarget's anchor,
  extracted); a tombstoned selection never anchors; lane paste reaches the
  right end and stays enabled on a zero-lane board; paste into the source
  board is the within-board lane duplicate; copies keep created, take
  fresh GUIDs, and strip tombstoned cards; trash-sourced copies strip
  deleted: at materialization; ⌘X is disabled on the trash side.
- A degraded paste is loud, never silent: staging gone → the embedded
  index.md fallback lands content-intact, attachments absent, and a
  BannerCenter-phrased row names what was lost.
- The standard Edit items validate through conditionally-attached
  onCommand handlers, so AppKit's enablement mirrors the availability
  predicates; text fields keep their own clipboard while focused.

879 unit tests (68 new).

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

Kanban/UI/Board/PasteTarget.swift

@@ -0,0 +1,76 @@
+/// Where ⌘V lands (04-interactions.md ▸ Clipboard), as pure functions of the selection, the
+/// last-active lane, and the snapshot (`PasteTargetTests`).
+///
+/// The two rules verbatim, and each clause's branch below:
+///
+/// > Paste lands after the anchor card (or appends to a selected lane); a multi-selection anchors at
+/// > its last member in flatten order — the ⌘N target rule's shared anchor. … **A tombstoned
+/// > selection never anchors paste**: ⌘V stays enabled and behaves exactly as with nothing selected —
+/// > a card payload appends to the last-active lane, a lane payload lands at the board's right end.
+///
+/// > **Lane paste** lands after the anchor lane — the selected lane, or the selected card's lane
+/// > (several selected: the last, per the shared anchor rule); nothing selected = the board's right
+/// > end.
+///
+/// Plus 04 ▸ The map's zero-lane clause: "New Card, Return-creation, and Paste with a *card* payload
+/// disable via menu validation until a lane exists … Paste with a **lane** payload … stays enabled
+/// and lands at the board's right end".
+///
+/// **Pure, for `NewCardTarget`'s reason** — the branches become lines of test rather than gestures to
+/// drive, and the menu item's `disabled` reads the *same* answer as the paste's own target rather
+/// than a second, hand-kept-in-sync condition.
+///
+/// ### What it deliberately reuses
+///
+/// The anchor is `NewCardTarget.flattenAnchor`, not a second walk: 04 says creation and paste share
+/// one anchor ("the ⌘N target rule's shared anchor"), and two derivations of "the last member in
+/// flatten order" would be two chances for them to disagree. The card branch goes further and reuses
+/// `NewCardTarget.resolve` whole, because a card paste's *fallback* is the ⌘N rule's fallback too —
+/// the last-active lane, then the first lane. Only the lane branch stops at the anchor, because its
+/// fallback is the board's right end instead.
+enum PasteTarget {
+
+    /// Where a card payload lands: which lane, and the position among that lane's rendered cards.
+    struct Cards: Equatable {
+        let laneID: ItemID
+        /// A position in the lane's logical card order, counted among what it renders *now* — the
+        /// convention every arrival path here takes (`BoardStore.receiveCards`).
+        let index: Int
+    }
+
+    /// The card payload's target, or `nil` on a **zero-lane board** — which is therefore the menu
+    /// item's `disabled` condition as well as the paste's refusal, so the two cannot disagree.
+    static func cards(
+        selection: ItemReferenceSet,
+        lastActiveLaneID: ItemID?,
+        snapshot: BoardModel
+    ) -> Cards? {
+        guard let resolution = NewCardTarget.resolve(
+            selection: selection,
+            lastActiveLaneID: lastActiveLaneID,
+            snapshot: snapshot
+        ),
+            let lane = snapshot.lanes.first(where: { $0.id == resolution.laneID && !$0.isDeleted })
+        else { return nil }
+
+        let rendered = lane.cards.filter { !$0.isDeleted }
+        // `insertionIndex` answers `nil` for "append", which is `rendered.count` — the same position
+        // said two ways, and the creation path's own degradation for an anchor that has since gone.
+        let index = BoardStore.insertionIndex(after: resolution.anchorCardID, among: rendered) ?? rendered.count
+        return Cards(laneID: lane.id, index: index)
+    }
+
+    /// The lane payload's slot among the board's live lanes — **always an answer**, zero-lane board
+    /// included, because lane paste "stays enabled and lands at the board's right end" whatever the
+    /// board holds. That is what makes it the other way out of a board with no lanes.
+    static func lanes(selection: ItemReferenceSet, snapshot: BoardModel) -> Int {
+        let lanes = snapshot.lanes.filter { !$0.isDeleted }
+        guard let anchor = NewCardTarget.flattenAnchor(selection: selection, snapshot: snapshot),
+              let position = lanes.firstIndex(where: { $0.id == anchor.laneID })
+        else {
+            // Nothing selected, a tombstoned selection, or a stale one: the right end.
+            return lanes.count
+        }
+        return position + 1
+    }
+}