feat(v1.1.9): invoke:: Rhai SDK module — sync re-entry + invoke_async

executor-core/sdk/invoke.rs adds `invoke()` and `invoke_async()` as
top-level Rhai helpers (no `::` namespace, mirroring the brief):

  invoke(target, args)        -> Dynamic  (sync, returns callee's value)
  invoke_async(target, args)  -> String   (fire-and-forget; returns execution_id)

Sync re-entry pattern:
  - bridge captures Arc<Engine> via Engine::self_arc()
  - calls engine.execute(&source, req) directly — same engine instance,
    same Services, same Limits; only SdkCallCx changes per call
  - runs inside the caller's spawn_blocking thread (no nested
    spawn_blocking, no gate re-admission — the outer execution already
    holds a permit)

Back-reference plumbing:
  - Engine gains self_weak: OnceLock<Weak<Engine>> + set_self_weak() +
    self_arc() accessor
  - picloud binary calls engine.set_self_weak(Arc::downgrade(&engine))
    right after construction
  - register_all extended with limits + Option<Arc<Engine>> params
  - Engine::execute_ast threads both through

Limits.trigger_depth_max added — mirrors TriggerConfig::max_trigger_depth.
Default 8; the picloud binary syncs from TriggerConfig::from_env() so
PICLOUD_MAX_TRIGGER_DEPTH governs both the dispatcher's fan-out cap and
the invoke depth bound.

Target parsing (string-first):
  - "/api/foo"             → InvokeTarget::Path
  - 36-char UUID-like      → InvokeTarget::Id  (uuid::Uuid parse-validated)
  - everything else        → InvokeTarget::Name

Cross-app + depth + FnPtr guards:
  - resolve() returns InvokeError::CrossApp if resolved.app_id != cx.app_id
  - bridge throws "invoke: depth limit exceeded (max N)" when
    cx.trigger_depth + 1 > limits.trigger_depth_max (checked BEFORE
    resolve to avoid a wasted DB round-trip)
  - args_to_json rejects FnPtr at any depth — closures don't survive
    invoke boundaries

invoke_async path:
  - calls services.invoke.enqueue_async() which writes an
    OutboxSourceKind::Invoke row (commit 10 wires the dispatcher arm)
  - returns the new ExecutionId as a string for caller tracking

Integration tests (sdk_invoke.rs, 6 binaries):
  - sync invoke returns callee's value (script returns body.x + 1)
  - cross-app invoke rejected (target in other app)
  - depth limit exceeded (recursive script that calls itself; throws
    before stack overflow)
  - callee receives incremented depth in cx (smoke — strict assertion
    needs ctx.trigger_depth surface, deferred to v1.2)
  - args_to_json rejects FnPtr in payload
  - invoke_async returns valid UUID string + queues args payload

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

crates/executor-core/src/sandbox.rs

@@ -30,6 +30,16 @@ pub struct Limits {
     /// Not script-overridable (this is a platform-level guard, not a
     /// per-script knob).
     pub module_import_depth_max: u32,
+
+    /// v1.1.9: hard ceiling on `cx.trigger_depth` (shared between
+    /// trigger fan-out and `invoke()` re-entry). The dispatcher uses
+    /// `TriggerConfig::max_trigger_depth` for the SAME bound; the
+    /// invoke bridge uses this Limits-side mirror to short-circuit
+    /// before a DB round-trip. Defaults to 8 (matches
+    /// TriggerConfig::conservative); the picloud binary keeps the two
+    /// in sync by passing `TriggerConfig::from_env().max_trigger_depth`
+    /// through.
+    pub trigger_depth_max: u32,
 }
 
 impl Default for Limits {
@@ -42,6 +52,7 @@ impl Default for Limits {
             max_call_levels: 64,
             max_expr_depth: 64,
             module_import_depth_max: 8,
+            trigger_depth_max: 8,
         }
     }
 }
@@ -75,6 +86,9 @@ impl Limits {
             // module_import_depth_max is platform-level — overrides
             // never touch it. Carry through unchanged.
             module_import_depth_max: self.module_import_depth_max,
+            // trigger_depth_max is also platform-level (v1.1.9 invoke
+            // depth bound mirrors the dispatcher's trigger-depth cap).
+            trigger_depth_max: self.trigger_depth_max,
         }
     }
 }