feat(workflow): add managed definitions, conditional routing, delegation, escalation, quorum, and approval inbox #747

Parent epic: #738
Depends on: #739
Related completed foundations: existing workflow module, #681, #697

Context

The current workflow approval foundation supports reusable approval behavior, but enterprise-derived applications need managed versioned definitions, conditional and parallel routing, delegation/substitution, escalation/timeouts, quorum rules, and a consolidated approval inbox. These capabilities must remain generic and must not introduce a heavy external BPMN engine into the base.

Objective

Evolve the existing workflow module into a safe enterprise workflow minimum while preserving immutable active definitions, deterministic instance history, default-deny authorization, and module-owned domain decisions.

Scope

• Add managed workflow-definition CRUD with draft, validate, publish/activate, retire, and version history.
• Define generic nodes/transitions for:
  • sequential approval;
  • conditional routing based on validated bounded facts;
  • parallel branches;
  • quorum/any/all approval rules;
  • notification/manual task nodes where already supported by capability ports.
• Ensure each workflow instance is pinned to the definition version used at start.
• Add delegation/substitute assignments with effective dates, scope, reason, and audit.
• Add escalation and timeout policies processed by shared jobs with bounded batches, locks, and idempotency.
• Add reassignment/cancellation/administrative recovery rules with explicit permissions and immutable history.
• Add a consolidated admin/operator approval inbox with pagination, filters, due/overdue state, safe search, and action history.
• Define a workflow context contract that references domain resources without writing their tables or embedding arbitrary expressions/code.
• Allow module-contributed condition resolvers/actions through static capability ports and schema-validated facts.
• Add workflow events to AsyncAPI and transactional outbox integration when feat(domain-events): add transactional event outbox, idempotent consumers, retries, ordering, and dead-letter handling #742 is available; until then preserve compatibility with existing event patterns.
• Add metrics for active/overdue instances, action latency, escalation, timeout, conflict, and failure without high-cardinality labels.

Security and integrity requirements

• Published/active workflow definitions are immutable; changes create a new version.
• Existing instances remain pinned to their original version and continue deterministically.
• Self-approval remains denied where requester and approver conflict; SoD hooks from feat(identity-access): add reusable business-scope assignments and segregation-of-duties policy hooks #746 are used when available.
• Condition evaluation cannot execute arbitrary code, SQL, templates, or tenant-uploaded expressions.
• Unknown resolver/action, missing facts, stale scope, or authorization ambiguity defaults to deny/pause with safe operator evidence.
• Delegation never broadens tenant or business scope beyond the delegator's verified authority.
• Administrative recovery, bypass, cancel, or reassign actions require explicit permission, reason, idempotency where high-risk, and audit.

Out of scope

• Full BPMN 2.0 engine or external workflow/orchestration dependency.
• Domain-specific forms, finance approvals, HR rules, procurement rules, or regulatory workflow content in the base.
• Arbitrary scripting in conditions or actions.

Acceptance criteria

• Draft definitions can be validated, versioned, activated, and retired; active versions cannot be edited in place.
• Instances remain pinned to their starting version after a newer definition is published.
• Sequential, conditional, parallel, and quorum fixtures execute deterministically.
• Delegation/substitution respects effective dates, tenant/scope, expiry, and audit.
• Escalation/timeouts are idempotent, resumable, and safe after worker interruption.
• Self-approval and unauthorized administrative recovery are rejected by negative tests.
• Module conditions/actions are registered statically and cannot execute arbitrary code.
• Approval inbox is paginated, filterable, accessible, tenant-safe, and shows immutable action history.
• Cross-tenant RLS/ABAC, concurrency/double-action, version pinning, timeout, delegation, quorum, and recovery tests pass.
• OpenAPI/AsyncAPI, ERD/data dictionary, workflow docs, threat model, admin/user guide, jobs/runbook, repository inventory, and changeset are updated.
• bun run api:spec:check, bun run security:readiness, bun run test, UI/E2E checks, and bun run check pass.