feat(executor): expose ctx.trigger_depth and pin the invoke depth bump

`invoke_callee_sees_incremented_depth` asserted NOTHING — it ended `let _ = resp`
with a comment that `ctx.trigger_depth` wasn't exposed, so it would have passed
even if `invoke` forwarded the depth unchanged, i.e. never incrementing the
chain-depth counter that bounds runaway trigger loops.

`build_ctx_map` now surfaces `ctx.trigger_depth` (read-only: 0 for direct ingress,
+1 per synchronous `invoke` re-entry or dispatched handler) — the value the
author intended to read and a legitimate diagnostic for a script. The test now
pins the increment: the caller is depth 0, the invoke callee must see 1.

Mutation-verified: forwarding the depth unchanged makes the callee see 0 and the
test fails.

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

crates/executor-core/src/engine.rs

@@ -498,6 +498,14 @@ fn build_ctx_map(req: &ExecRequest) -> Map {
         "invocation_type".into(),
         invocation_type_str(req.invocation_type).into(),
     );
+    // Read-only depth of this call in a trigger/invoke chain: 0 for direct
+    // ingress, +1 per synchronous re-entry (`invoke`) or dispatched handler.
+    // Exposed so a script can observe where it sits in the chain (the same value
+    // the platform bounds via `trigger_depth_max`).
+    ctx.insert(
+        "trigger_depth".into(),
+        (i64::from(req.trigger_depth)).into(),
+    );
 
     let mut request = Map::new();
     request.insert("path".into(), req.path.clone().into());