feat(idm): govern delegation chains and timed escalation

docs/FUNCTION_ASSIGNMENT_WORKFLOWS.md

@@ -53,8 +53,13 @@ creates them:
   assignment or represented account.
 
 The Organizations function must permit the requested mode. The source and
-derived assignments must belong to the same tenant and function, and the
-source must be current and active. An actor also needs the assignment-write
+derived assignments must belong to the same tenant, function, and unit scope.
+IDM walks the complete source chain at submission, every decision, recovery,
+and final application. Cycles, missing or inactive sources, expired windows,
+child windows outside their source, and chains beyond the current Policy depth
+ceiling fail closed with a specific explanation. Tightening Policy therefore
+invalidates a formerly acceptable route; captured submission authority is
+evidence, not a future permission grant. An actor also needs the assignment-write
 scope; where a governance profile is enabled, Policy must authorize the
 request/grant or an administrator must use the recorded emergency-override
 path. Validity windows make substitutions expire automatically. Deactivation
@@ -96,7 +101,7 @@ IDM persists one function-assignment change aggregate for both journeys:
 
 Candidate states are `draft`, `submitted`, `awaiting_holder`,
 `awaiting_authority`, `awaiting_recipient`, `changes_requested`, `blocked`,
-`approved`, `accepted`, `applied`, `rejected`, `withdrawn`, `expired`,
+`escalated`, `approved`, `accepted`, `applied`, `rejected`, `withdrawn`, `expired`,
 `cancelled`, and `failed_manual_review`. Not every profile uses every state.
 
 The workflow instance coordinates the process, but the IDM change record is the
@@ -133,7 +138,14 @@ override only the corresponding defaults. Supported keys include
 `request_profile`, `grant_profile`, `authority_function_id`,
 `recipient_acceptance_required`, `evidence_required`,
 `separation_of_duties`, `quorum`, `maximum_validity_days`, and
-`request_expiry_hours`. Missing or malformed profiles fail closed.
+`request_expiry_hours`. Delegation uses `delegation_allowed`,
+`maximum_delegation_depth`, and `maximum_delegated_validity_days`. The optional
+`escalation` object has `holder`, `authority`, or `recipient` entries; each entry
+requires an exact `target_function_id` and a bounded `timeout_hours`. Missing or
+malformed profiles and half-configured escalation rules fail closed. Tenant
+administrators can edit these defaults in the IDM governance panel, while a
+function-specific Organizations setting may only tighten or deliberately
+override the corresponding default with visible Policy provenance.
 
 IDM exposes governed changes at
 `/api/v1/idm/function-assignment-changes`. Mutations require a strong `If-Match`
@@ -141,7 +153,13 @@ precondition and the aggregate revision. Requests and grants pin the exact
 Workflow definition revision and hash, retain append-only transition evidence,
 support review change requests and responses, and apply an assignment exactly
 once. Vacant holder or authority functions create a visible `blocked` state;
-the lifecycle worker expires overdue open changes durably.
+the lifecycle worker expires overdue open changes durably. When a configured
+review deadline elapses, the worker atomically changes the aggregate to
+`escalated`, retains the original review state and exact target function,
+notifies the participants and target holders, and records change, Platform
+Event, and Audit evidence. It never marks the review complete. A current holder
+of that explicit target must make a normal revision-checked decision. Recovery
+rechecks the current route and cannot manufacture an approver.
 
 Direct administration remains available for independently deployed IDM. When
 a function has an enabled governance profile, however, direct create or update