improvement(condition): batch condition evaluation into one sandbox call, and stop the transport from undercutting a route's own deadline (#6854)

* fix(tools): give internal routes transport headroom past their execution budget

A `timeout` param bounds the work an internal route was asked to do — the code
a sandbox runs, the upstream call a proxy route makes. The fetch around it also
pays authentication, body parsing, workspace authorization, worker acquisition,
and response serialization, none of which that budget was sized for. Arming the
client with the bare number made the caller give up at the same instant the
route's own deadline fired, so the route could never win the race and report
which part actually ran long — the caller saw an unattributable
`Request timed out` instead of `Function execution timed out after 5000ms`.

Add 30s of headroom, sized above the isolated-vm worker's own 10s startup
budget so a cold worker spawn stays inside the transport deadline rather than
aborting it. An execution abort signal, when present, still bounds the call.

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

* improvement(executor): evaluate a condition list in one sandbox call

A condition block spent one `function_execute` round trip per branch, so a
four-branch block that fell through to `else` paid four sandbox executions
before routing. Build one script that tests each expression in order and
returns the index of the first truthy one.

Ordering and short-circuiting are unchanged: an expression is only reached once
every earlier one returned falsy, so a later expression that throws is still
never reached and the run takes the same branch it took before. The script's
`catch` reports the index it was on as data rather than rethrowing, which is
what lets the handler still name the failing branch in its error.

A batch that produces no verdict falls back to one call per branch — the path
this handler used before. That is load-bearing rather than redundant: a syntax
error anywhere in the list fails the whole script at parse time, while
evaluating one at a time only reaches, and so only fails on, the branches the
run actually takes. A timed-out or cancelled batch skips the fallback, which
would otherwise re-run every branch against the same stall.

An unrecognized reply is treated as no verdict rather than as "nothing
matched", so a garbled response cannot silently route the run down the else
path.

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

* fix(executor): wrap condition expressions the same way in both paths

The batched script put each expression on its own line inside `Boolean(...)`
so a trailing line comment ended before the closing parenthesis; the per-branch
fallback still inlined `Boolean(${expression})` on one line. That made the
recovery path stricter than the path it recovers — a batch that failed to parse
because of a later branch would fall back and then reject an earlier
comment-bearing branch it should have matched.

Both paths now wrap through `buildBooleanTest`, so they cannot drift again.
Also narrows the evaluation-context boundary from `Record<string, any>` to
`Record<string, unknown>`; the context is only ever serialized, never indexed.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321