docs(approvals): regenerate the ExecutionContext reference; document the lock's two new behaviours

The `flowRunId` field added to `ExecutionContextSchema` left the GENERATED
`content/docs/references/kernel/execution-context.mdx` stale, failing the spec
`check:docs` gate. Regenerated via the prescribed path (`gen:schema && gen:docs`)
— a one-row addition to the field table.

Also updates the hand-written approvals guide, which described the record lock as
absolute and predated any automatic recovery:

- the lock now exempts the run that opened the request, and the exemption is
  keyed on run identity rather than elevation, so a `runAs:'user'` run stays
  RLS-scoped while it writes;
- a dead run's lock is released by the sweep, with the note that it acts only on
  a positively-confirmed terminal run — a paused run, an unknown run, or an
  unreachable engine all count as alive.

`check:docs` and `check:doc-authoring` both green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JGXCuBt5mSXbN3Gc8yfbRv

Author: claude

content/docs/automation/approvals.mdx

@@ -210,6 +210,12 @@ The node writes a `sys_approval_request` row: `status: 'pending'`,
 record is **locked** against edits while pending (`lockRecord`, default `true`),
 and the flow run parks until a decision arrives.
 
+The lock applies to everyone *except the run that opened the request*. A flow may
+still write its own target record while its own approval is pending, so it can
+never deadlock against itself. The exemption is keyed on run identity rather than
+elevation, so a `runAs:'user'` run stays row-level-security scoped while it
+writes — it does not become a system write.
+
 Only `approvers` is required on the node; everything else has a default
 (`behavior: 'first_response'`, `lockRecord: true`, `maxRevisions: 3`).
 
@@ -383,6 +389,20 @@ and is audited under the admin's own id. Prefer a guaranteed-staffed fallback
 approver so the set is never empty in the first place.
 </Callout>
 
+<Callout type="info">
+**A dead run releases its own lock.** If the flow run that opened an approval
+reaches a terminal state without a decision — it failed, was cancelled, timed
+out, or the process hosting it crashed — nothing is left to decide the request,
+so a periodic sweep finalizes it as `recalled` and releases the record. The
+audit row records the actor `system:dead-run` and names the run and its status,
+so it reads distinctly from a submitter's own recall.
+
+The sweep only ever acts on a run it can positively confirm is terminal: a
+paused run (the normal state of a live approval), an unknown run, or an
+unreachable automation engine all count as *alive* and are left untouched. It
+frees orphaned records; it never cancels a live approval.
+</Callout>
+
 ### Progress and notification deep links
 
 A pending multi-approver request also carries a **server-computed

content/docs/references/kernel/execution-context.mdx

@@ -66,6 +66,7 @@ const result = ExecutionContext.parse(data);
 | **accessible_org_ids** | `string[]` | optional |  |
 | **rlsMembership** | `Record<string, string[]>` | optional |  |
 | **isSystem** | `boolean` | ✅ |  |
+| **flowRunId** | `string` | optional |  |
 | **skipTriggers** | `boolean` | optional |  |
 | **skipAutomations** | `boolean` | optional |  |
 | **seedReplay** | `boolean` | optional |  |