[P1] Structured resource limits with typed errors in boruna_run

[escapeboy]

Reported by FleetQ. Today boruna_run accepts max_steps (and via the upstream VM, policy.net_policy.timeout_ms). A buggy or adversarial .ax script can still exhaust memory or fork-bomb the host process before any step or wall-clock limit fires.

Ask

boruna_run({
  script,
  policy,
  limits: {
    "max_memory_mb":    256,
    "max_wall_ms":      30000,
    "max_syscalls":     100000,
    "max_output_bytes": 1048576
  }
})

Returning typed errors:

{ "success": false, "error_kind": "limit_exceeded", "limit": "memory", "actual_mb": 312, "max_mb": 256 }

…so callers can surface a clean UX rather than a generic non-zero exit.

Notes for implementers

• max_wall_ms is straightforward via a tokio::time::timeout wrapper around the spawn_blocking call in crates/boruna-mcp/src/server.rs.
• max_memory_mb is harder — Rust process-level rlimits (setrlimit on Linux) work but are platform-specific. A simpler MVP: ship max_wall_ms first and document max_memory_mb as platform-best-effort.
• max_output_bytes can be enforced at the format_value step in tools/run.rs by tracking serialized size and aborting once exceeded.
• max_syscalls would require a seccomp filter on Linux — out of scope for v1.

---

Source: FleetQ implementer feedback letter, 2026-04-25 (P1 #5).