fix(executor): bound Rhai→JSON materialization to prevent anonymous OOM

The per-element Rhai sandbox caps (max_string_size 64 KiB, max_array_size /
max_map_size 10 000) do NOT bound the *materialized* size: Rhai shares strings
and arrays by Rc, so a 10 000-element array of one aliased 64 KiB string is
cheap to build (~10 000 ops, far under the 1 M op budget) yet dealiases to
~640 MiB of distinct JSON. Every Dynamic→JSON conversion deep-copies the
aliases; the HTTP response body path had NO size cap at all, and the KV/docs
value caps run only AFTER full materialization — so a handful of anonymous
requests could OOM the node (32 concurrent × ~640 MiB ≈ 20 GiB) on the stated
consumer-hardware target.

Add a byte-budgeted materializer that bails the moment the budget is exceeded,
so the transient allocation is bounded regardless of aliasing:
- bridge.rs: `dynamic_to_json_capped(value, max) -> Result<Json, JsonSizeError>`
  (charges a running budget) + `MAX_JSON_MATERIALIZE_BYTES` (16 MiB hard rail,
  far above the 256 KiB business caps). `dynamic_to_json` stays infallible for
  best-effort paths (logging) but is now internally bounded — it collapses an
  over-limit value to a marker string instead of OOMing.
- Route every user-value boundary through the fail-closed capped form: KV
  set/set_if (+ the CAS `expected`), docs create/update/find, secrets set,
  http request body, workflow input, `json::stringify`, and the HTTP RESPONSE
  body (previously the one fully-uncapped exit → now a 500). `invoke` args and
  the pubsub/queue message materializers get the same byte budget in place.
- `impl From<JsonSizeError> for Box<EvalAltResult>` so SDK sites protect
  themselves with a bare `?`.

Pinned by bridge unit tests: an aliased 10 000×64 KiB array errors on the
budget rather than materializing, and the infallible wrapper yields a marker
instead of OOMing. Workspace 914 + journeys 157/157 green.

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

crates/executor-core/src/engine.rs

@@ -57,7 +57,9 @@ use crate::module_resolver::{
 };
 use crate::sandbox::Limits;
 use crate::sdk;
-use crate::sdk::bridge::{dynamic_to_json, json_to_dynamic};
+use crate::sdk::bridge::{
+    dynamic_to_json, dynamic_to_json_capped, json_to_dynamic, MAX_JSON_MATERIALIZE_BYTES,
+};
 use crate::types::{
     ExecError, ExecRequest, ExecResponse, ExecStats, InvocationType, LogEntry, LogLevel,
 };
@@ -749,7 +751,11 @@ fn parse_response(value: Dynamic) -> Result<(u16, BTreeMap<String, String>, Json
             }
         }
     }
-    Ok((200, BTreeMap::new(), dynamic_to_json(&value)))
+    // The response body is otherwise an uncapped Rhai→JSON exit — bound it so a
+    // cheaply-aliased huge value can't OOM the node on materialization.
+    let body = dynamic_to_json_capped(&value, MAX_JSON_MATERIALIZE_BYTES)
+        .map_err(|e| ExecError::InvalidResponse(e.to_string()))?;
+    Ok((200, BTreeMap::new(), body))
 }
 
 fn parse_structured_response(map: Map) -> Result<(u16, BTreeMap<String, String>, Json), ExecError> {
@@ -771,7 +777,11 @@ fn parse_structured_response(map: Map) -> Result<(u16, BTreeMap<String, String>,
         }
     }
 
-    let body = map.get("body").map_or(Json::Null, dynamic_to_json);
+    let body = match map.get("body") {
+        Some(b) => dynamic_to_json_capped(b, MAX_JSON_MATERIALIZE_BYTES)
+            .map_err(|e| ExecError::InvalidResponse(e.to_string()))?,
+        None => Json::Null,
+    };
 
     Ok((status_code, headers, body))
 }