Per-action failure policy, so a chain can stop instead of running past a failure

A failed action does not stop the ones after it. The run is marked PartiallyFailed and everything later still runs (`WorkflowRunner.cs:258-289`).

That is a deliberate choice, recorded in the comment there and attributed to #329: "These are usually independent, and skipping the tweet because the mail server was down is a surprise nobody asked for."

For notifications it is right. For a chain it is not. If the journal entry fails, filing the document, adjusting stock and reordering from the supplier should not proceed as though it succeeded.

Both behaviours are correct for their own case, which is why this is a per-action setting rather than a change of default.

## What to add

`OnFailure: Continue | Halt` on `WorkflowAction`, defaulting to `Continue` so nothing existing changes.

With `Halt`, the remaining attempts are marked `Skipped` rather than left `Pending`, and the run is terminal. Skipped rather than Pending matters: a Pending attempt looks like work the runner will get to, and the poll loop would keep visiting it.

The existing per-action retry endpoint (`Features/WorkflowRuns/Endpoints.cs:191-264`) then becomes a resume: fix the cause, retry the halted action, and the skipped ones become due again. That is the same shape as the resume in other engines, and most of it is already built.

## Done when

- An action marked Halt that fails permanently leaves later actions Skipped, not run.
- Retrying the halted action makes the skipped ones runnable again.
- A workflow with no `OnFailure` set behaves exactly as it does today.

Start with WorkflowRunner.cs:258-289 and the WorkflowAction model to trace failure handling and the default behavior. Then read Features/WorkflowRuns/Endpoints.cs:191-264 for the existing retry flow. Done means Halt marks later attempts Skipped after a permanent failure, retrying resumes them, and unset OnFailure preserves current behavior.

Written by the indexing model from the issue text.