CW-v1: content workflow engine (revision-aware, group-routable)

[jonesrussell]

Anchoring issue for the CW-v1 feature (per docs/specs/workflow.md rule 2 — every PR in this effort references this issue).

Client-driven framework feature resolving audit decision D1: a general content-workflow engine replacing the dead node-specific editorial machinery. Design bar: Drupal content-moderation parity and beyond.

Shape (spec: docs/specs/content-workflow.md):

• Workflow definitions as CMI-syncable config entities; default editorial workflow ships as data, not code
• Workflow state on revisions (forward drafts; approval promotes the draft revision) on the existing two-axis RevisionableStorageDriver substrate
• One engine door: TransitionService (validate → apply → events) + getAvailableTransitions()
• Save-path guard: raw PATCH ≡ service call; create forces initial state (no born-published content without the publish permission)
• Gating: per-transition permissions + optional group (department) constraints — beyond-parity routing
• Audit via audit package public API (downward import); notifications subscribe to transition events

Work packages:

• WP-0: interim status/workflow_state field gate (ships on R16 timeline, permission name engine-compatible)
• WP-1: config schema + TransitionService + save-path guard + events + permissions + default workflow
• WP-2: node opt-in to revisionable storage + migration; forward-draft flow end-to-end
• WP-3: group-constraint dimension (groups readiness assessment first)
• WP-4: API endpoints + admin SPA transition UI
• WP-5: delete dead machinery (EditorialWorkflowService, EditorialTransitionAccessResolver, AuthoringRoleMatrix, DomainValidationListener, dry-run/guards controllers) + README truth-up

🤖 Generated with Claude Code