test(auditlog): end-to-end ParentExecutionId correlation + docs

docs/requirements/Component-AuditLog.md

@@ -84,6 +84,7 @@ row per lifecycle event across all channels.
 | `Kind` | `varchar(32)` | Event kind discriminator (see kinds list below). |
 | `CorrelationId` | `uniqueidentifier` NULL | Ties multi-event operations together. `TrackedOperationId` for cached calls, `NotificationId` for notifications, request-id for inbound API. NULL for sync one-shot calls. |
 | `ExecutionId` | `uniqueidentifier` NULL | The originating script execution / inbound request — the universal per-run correlation value; distinct from `CorrelationId`, which is the per-operation lifecycle id. Stamped on *every* audit row emitted by one execution. |
+| `ParentExecutionId` | `uniqueidentifier` NULL | The `ExecutionId` of the execution that *spawned* this run — the cross-execution correlation pointer. Set on every row of an inbound-API-routed site script run (= the inbound request's `ExecutionId`); NULL for a top-level run (inbound, tag-change / timer-triggered, un-bridged). |
 | `SourceSiteId` | `varchar(64)` NULL | NULL for central-originated events. |
 | `SourceInstanceId` | `varchar(128)` NULL | Instance whose script initiated the action (when applicable). |
 | `SourceScript` | `varchar(128)` NULL | Script name within the instance. |
@@ -105,6 +106,7 @@ row per lifecycle event across all channels.
 - `IX_AuditLog_Site_Occurred (SourceSiteId, OccurredAtUtc)` — per-site filters.
 - `IX_AuditLog_CorrelationId (CorrelationId)` — drilldown from a single operation.
 - `IX_AuditLog_Execution (ExecutionId)` — drilldown to every action of one script execution / inbound request.
+- `IX_AuditLog_ParentExecution (ParentExecutionId)` — cross-execution drilldown: the downward leg of the execution-tree walk seeks on it (`ParentExecutionId = ancestor.ExecutionId`), and it backs the `parentExecutionId` filter.
 - `IX_AuditLog_Channel_Status_Occurred (Channel, Status, OccurredAtUtc)` — KPI / dashboard tiles.
 - `IX_AuditLog_Target_Occurred (Target, OccurredAtUtc)` — "what did we send to system X".
 - Monthly partitioning on `OccurredAtUtc` from day one; purge is a partition switch (see Retention & Purge).
@@ -149,6 +151,22 @@ The table carries two correlation columns at different granularities:
 The two are orthogonal: one execution may touch several operations (each with
 its own `CorrelationId`) yet every resulting row shares the one `ExecutionId`.
 
+**`ParentExecutionId`** adds *cross-execution* correlation on top. `ExecutionId`
+is per-run and flat — `WHERE ExecutionId = X` returns everything one run did, but
+nothing links a run to the run that *spawned* it. `ParentExecutionId` carries the
+spawning execution's `ExecutionId`: a spawned run still gets its own fresh
+`ExecutionId`, and every audit row it emits also carries the spawner's id in
+`ParentExecutionId`. The first cut bridges the **inbound API → routed-site-script**
+case: an inbound request runs a method script that calls `Route.Call`, routing to
+a site instance; the routed site script records the inbound request's
+`ExecutionId` as its `ParentExecutionId`, while the inbound `InboundRequest` row
+itself is top-level (`ParentExecutionId` NULL). The pointer always references the
+*immediate* spawner, so a routed run that itself routes onward threads its own
+`ExecutionId` — walking `ParentExecutionId → ExecutionId` recursively
+reconstructs the call chain as a tree of arbitrary depth. The tag-cascade case
+(an attribute write triggering another script) is **deferred** — the model
+generalises to it with no schema change once that spawn point is threaded.
+
 ## The Site-Local `AuditLog` (SQLite)
 
 A SQLite database file on each site node, alongside the Store-and-Forward