feat: Implement state management, undo / redo capabilities and component API #318

Description

Implement state management and undo / redo capabilities to handle model changes in the store and expose an API to interact with it.

Motivation

This is the foundation for the "Edit then Save" pattern. It can be quite inconvenient if changes cannot be rolled back as the user edits tasks.

Proposed Implementation

• Implement a stack of model states as the model changes
• Limit the size of the stack (number of undo / redo operations supported)
• Handle states coming in and out as the stack reaches its size limit
• Handle fork, when the user undoes to a certain state in the stack and from that point a new state is created
  • The states out of the fork sequence must be removed
• Expose an imperative ref API on DiagramEditor with undo(), redo(), canUndo, canRedo, getContent(), and setContent() members
• History recording must be scoped to edit mode only (isReadOnly={false})
• Serialisation format (YAML or JSON) must be auto-detected on load and preserved across undo/redo operations
• Preserve the selected node/edge across content reloads when the task ID still exists in the new model
• Preserve the viewport state (pan, zoom) across undo/redo operations so the user's view position is restored with each history step

Definition of Done

• Implementation: Fully implemented according to the Open Workflow spec.
• Unit Tests: Comprehensive unit tests are included and passing.
• Integration Tests: Verified within the monorepo and target environments (Web/VS Code).
• Documentation: Updated README.md, ADRs, or official docs.
• Performance: No significant regression in editor responsiveness.
• Accessibility: UI changes comply with accessibility standards.

Out of scope

• Keyboard shortcuts (Ctrl+Z / Ctrl+Y)
• Undo/redo toolbar buttons built into the diagram chrome
• Node property editing from the side panel
• Persisting history across page reloads