docs(workflow): admit the node:vm escape concretely — absent globals are surface, not containment

The review's critical finding: the engine README and the tool
description read as if the missing filesystem/network/Node globals were
enforced, but a script can reach the host Function constructor via
globalThis.constructor.constructor and from it process and every Node
builtin. Per the trust premise this is ACCEPTED (model-written scripts,
bash-equivalent trust; genuine sandboxing is the deferred engine swap
already listed) — but the docs must say so instead of implying a wall.
The trust-premise sections (engine README, module doc, RFC) now name
the escape and its acceptance; the model-facing tool description says
the APIs are not PROVIDED rather than implying they are prevented.

packages/workflow/workflow-vm/src/index.ts

@@ -7,9 +7,12 @@
  * TRUST PREMISE: scripts are MODEL-WRITTEN — the same trust level as the
  * model's existing bash access — so this engine defends against BUGGY
  * scripts, never hostile ones. vm is NOT a security boundary and no attempt
- * is made to contain adversarial values (see ./realm.ts); genuine sandboxing
- * is an engine swap behind the seam (worker-thread/isolated-vm), not
- * incremental host-side defenses here.
+ * is made to contain adversarial values (see ./realm.ts); the context is
+ * escapable by construction (the host `Function` constructor is reachable via
+ * `globalThis.constructor.constructor`, and `process` from there), so the
+ * absent globals are API surface, not containment. Genuine sandboxing is an
+ * engine swap behind the seam (worker-thread/isolated-vm), not incremental
+ * host-side defenses here.
  *
  * Engine limitations, documented as the accepted cost of the in-process
  * mechanism: