#4698 Docs: automatic continuation of interrupted runs in swamp serve (autoContinue)

Follow-up to #4693, which makes swamp serve continue an interrupted run on its own when that is safe.

Manual pages to update in content/manual:

• reference/workflows.md: document the new top-level autoContinue field (default true; false leaves interrupted runs for an operator). Explain how it differs from autoResume, which governs resuming after approvals and signal waits.
• reference/swamp-serve/audit-actions.md: add workflow.auto_continue, workflow.auto_continue_refused (reason= and step=) and workflow.auto_continue_failed. List the refusal reasons: opted_out, definition_changed, unguarded_step, fan_out_changed, nested_run_unsettled, workflow_missing, not_serve_driven, continued_too_often.
• how-to/make-workflows-idempotent.md: a guard now also decides whether serve continues a run cut off by a restart without an operator. Write guards that detect finished work.
• how-to/swamp-serve/run-multi-instance-deployment.md (or the restart guidance): after a restart, a crash or a leader change, safe interrupted runs continue under the same run id; exactly one instance continues each run. A continued webhook run does not count against the route maxConcurrentRuns. Unsafe runs stay interrupted and are named in the boot log, with swamp workflow recover as the next step.
• operational-tasks/clear-stuck-runs.md: mention that interrupted runs may already have been continued automatically. Show how to tell from swamp run history and swamp workflow history get.