• Implement crash recovery features and update documentation

If the server restarts while a workflow is running, the run used to get stuck as "running" and was eventually dropped with no record. Now those runs are picked up automatically and re-run from scratch with the same inputs, so they finish and show up in history.

How it works

Each running execution now stores what it needs to replay (inputs, trigger source, actor).
On startup the leader process finds interrupted runs and re-runs them in parallel. Recovery is instant on a graceful restart, or within about 60s after a hard crash.
A run is retried once. If it fails again, or the workflow was deleted, it is recorded as failed.
A per-workflow "Auto-recover runs" toggle (on by default) lives in the Properties panel when no node is selected. Turn it off to mark interrupted runs as skipped instead of re-running them.
Works the same on a single container and on multi-worker deployments. Only the leader recovers, so a run is never recovered twice.

UI

History shows skipped and failed status badges, plus a "Recovered" marker (icon in the list, full label on the detail panel).

Notes

Sub-workflows are not recovered on their own, the parent re-drives them.
Triggers with their own redelivery (RabbitMQ, cron, IMAP) can run a recovered job twice. This was a known, accepted tradeoff.