docs(workflows): errors are execution semantics — own section on how-it-runs

Failure behavior was buried inside 'Watching a run' (the live-UI section). Now
a first-class 'When a block fails' section in the execution story: an error
fails the run (in-flight blocks finish, nothing new starts) unless the block's
error port is connected, in which case the run follows the error path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: ouiliame

apps/docs/content/docs/en/workflows/how-it-runs.mdx

@@ -38,9 +38,13 @@ To repeat work, a [Loop](/blocks/loop) block runs its inner blocks over a list,
 A workflow can call other workflows, through a Workflow block, an MCP tool, or an API block. Sim tracks the call chain and stops a run that exceeds 25 hops, so workflows that call each other can't loop forever.
 </Callout>
 
+## When a block fails
+
+A block that errors fails the run: blocks already running finish, and nothing new starts. To handle the failure instead, connect the block's **error port** — the run follows the [error path](/workflows/connections) and continues.
+
 ## Watching a run
 
-While a workflow runs, the editor shows each block's state live: queued, running, done, or errored. When a block fails, the run fails with it — blocks already running finish, but nothing new starts. The exception is a block with its error port connected: the failure routes down the [error path](/workflows/connections) and the run continues. Every run is recorded, so you can open the [logs](/logs-debugging) to see what each block received and returned after it finishes.
+While a workflow runs, the editor shows each block's state live: queued, running, done, or errored. Every run is recorded, so you can open the [logs](/logs-debugging) to see what each block received and returned after it finishes.
 
 ## Next