fix(audit-2026-06-11/H-C1): engine.on_progress deadline check terminates runaway scripts

tokio::time::timeout over JoinHandle only drops the future — the
spawn_blocking OS thread keeps running until the Rhai script self-
completes or hits the per-op budget. A `loop {}` body with a generous
max_operations could pin a blocking worker for tens of seconds; on Pi-
class hardware one anonymous-callable script call could permanently
subtract a worker from the pool.

Installs an `engine.on_progress` hook that consults a thread-local
deadline; when `Instant::now() >= deadline` the hook returns `Some(_)`,
triggering `ErrorTerminated` inside the Rhai loop. The deadline is set
by `Engine::execute_with_deadline` / `Engine::execute_ast_with_deadline`
via an RAII `DeadlineGuard`, called from the orchestrator client; the
old `execute` / `execute_ast` paths are unchanged so tests, validation,
and the parse-only path keep working.

Invoke re-entry (`sdk/invoke.rs`) inherits the parent's deadline
transparently — the thread-local is set for the entire spawn_blocking
lifetime, and Rhai is single-threaded so the same thread services the
parent + every sub-script.

New tests:
* `deadline_terminates_a_runaway_loop` — `loop {}` body with
  `max_operations = u64::MAX` and a 100 ms deadline aborts within 2 s
  (typically <200 ms). Maps to `ExecError::Runtime`.
* `no_deadline_set_does_not_abort` — `None` deadline keeps the pre-
  audit behavior; the op-budget still bites.

Audit ref: security_audit/05_sandbox_exec.md#f-se-h-01.

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

crates/executor-core/tests/engine.rs

@@ -173,6 +173,55 @@ fn override_only_replaces_specified_field() {
     assert_eq!(resp.body, json!("hello"));
 }
 
+#[test]
+fn deadline_terminates_a_runaway_loop() {
+    // Audit 2026-06-11 H-C1 closure. With a generous op budget the
+    // previous engine ran a `loop {}` body until `max_operations`
+    // self-exhausted (potentially seconds on Pi-class hardware) and the
+    // outer `tokio::time::timeout` only dropped the awaiting future —
+    // not the OS thread. With `on_progress` consulting the deadline,
+    // a 100 ms deadline aborts within a few hundred ms even when the
+    // op budget would allow far more work.
+    let limits = Limits {
+        max_operations: u64::MAX,
+        ..Limits::default()
+    };
+    let engine = Engine::new(limits, Services::default());
+    let src = r"let n = 0; loop { n += 1; }";
+    let deadline =
+        Some(std::time::Instant::now() + std::time::Duration::from_millis(100));
+    let started = std::time::Instant::now();
+    let err = engine
+        .execute_with_deadline(src, req(json!(null)), deadline)
+        .expect_err("runaway loop must terminate");
+    let elapsed = started.elapsed();
+    assert!(
+        elapsed < std::time::Duration::from_secs(2),
+        "deadline should fire within ~hundreds of ms, took {elapsed:?}"
+    );
+    // ErrorTerminated maps to ExecError::Runtime via map_eval_error.
+    assert!(
+        matches!(err, ExecError::Runtime(_)),
+        "expected Runtime, got {err:?}"
+    );
+}
+
+#[test]
+fn no_deadline_set_does_not_abort() {
+    // Smoke: a deadline-less execute is unchanged from the pre-audit
+    // behavior — the per-op budget is what stops things.
+    let limits = Limits {
+        max_operations: 100,
+        ..Limits::default()
+    };
+    let engine = Engine::new(limits, Services::default());
+    let src = r"let n = 0; for i in 0..10000 { n += 1; } n";
+    let err = engine
+        .execute_with_deadline(src, req(json!(null)), None)
+        .expect_err("budget should still bite");
+    assert!(matches!(err, ExecError::OperationBudgetExceeded));
+}
+
 #[test]
 fn runtime_error_is_mapped_to_runtime_variant() {
     let err = engine()