annotator: full command-log store — execute/undo/redo, command grouping, commit-on-release for drags

[JArmandoAnaya]

Context

Undo/redo is a day-one foundation of the engine store, not a retrofit (vision doc decision
17). The bootstrap left execute/undo/redo signatures with one no-op test.

Deliverables

• Command interface (apply/invert or do/undo pair — decide, document) + log with
  cursor; redo stack invalidated on new commands.
• Command grouping/transactions (a polygon vertex drag = one undo step).
• Commit-on-release: transient drag state lives outside the log; only pointer-up commits a
  command (kills v1's re-render-per-pointer-move).
• Store is framework-free and subscribable (adapter-agnostic change notifications).

Acceptance criteria

• Property test: random command sequences + full undo returns the initial document
• Grouped commands undo atomically
• No document mutation during simulated drag until release

[JArmandoAnaya]

Done — PR #116, squash-merged as 22b5b3c. Fourth task of M4; the milestone is 4/14.

What shipped. A command is now a one-way document transformation (label + apply), and the log keeps the document that was there before it — so undo and redo are pointer swaps and apply runs exactly once, ever. That closes a live trap rather than tidying one: the scaffold called execute() again on redo, and a create-command mints a client-side uuid v4, so redo produced a different annotation and orphaned the selection keyed on the first id.

The rejected apply/invert pair loses on a single case: inverting a delete must restore the annotation's place in the draw order, and addAnnotation appends — so it would have to capture the removed annotations and their positions, plus a positional-insert operation the document does not have, to save one pointer.

• Grouping is composeCommands, not a protocol. A command is already an arbitrary transformation, so a group is composition threaded through the document — exception-safe for free. Deliberately no begin/commit/abort: an open transaction spanning pointer events is a state Escape can leave dangling, and nothing needs one.
• AnnotatorStore holds the document, its history, the selection beside it and a staging area, behind one subscription with a cached snapshot — the identity useSyncExternalStore requires, designed in one task before annotator: React adapter — SVG render, zoom/pan, asset image, annotation layer #47 would hit the infinite-render failure.
• A drag writes nothing. stage → commit/discard; the criterion-3 test drives ten pointer-moves and asserts the committed document is the same object (toBe) at the end as at the start. A projection is always applied to the committed document, so moves cannot stack.
• A throwing subscriber starves none of the others and is not swallowed — one AggregateError after everyone has run, because core has no logger.
• A command that returns the document it was given is not history, so removeAnnotations([]) does not leave an undo step that visibly does nothing.

Acceptance criteria

• Property test: random command sequences + full undo returns the initial document — six seeds × forty steps. Non-vacuous by construction: the expectation is built separately from the same ids and never handed to the store, and it compares an ordered array, which is the assertion the rejected design would fail.
• Grouped commands undo atomically.
• No document mutation during a simulated drag until release.

The property test also corrected its own first invariant: a run whose last step was an undo is sitting inside the log, not at its head, so "full redo returns where the run ended" is false — it returns to the head, which the test now walks to explicitly.

Ledger. No Python touched at all; FORMAT_VERSION 11, VERSION 0.0.1.dev0, openapi.json and the generated client both byte-identical. No new dependency — the property run uses sixteen lines of hand-written mulberry32 rather than fast-check, trading shrinking for a package that still ships zero dependencies, with the trade recorded in the harness docstring. 120 vitest tests, up from 86; five consecutive runs, 120/120 each.

Next: #41 — the 2D geometry port, the one M4 task takeable in parallel.