Document and stabilize the wasm command ABI (host ↔ guest module interface)

[NathanFlurry]

Problem

WASM command modules (registry/native/*) interface with the secure-exec runtime through an ABI that is currently implicit, undocumented, and evolving. It spans:

• the WASI target surface (wasm32-wasip1) the guest is compiled against,
• secure-exec's patched wasi-libc and custom extensions (e.g. networking — netdb.h/sockets — added via patches/wasi-libc/* + patch-wasi-libc.sh),
• the runtime-provided syscalls the kernel/sidecar exposes to the guest (fds, sockets, pty, process/spawn, signals),
• the command entry/dispatch contract (dispatch-by-header/magic-number, argv[0] multicall aliases, env, exit codes).

Because this contract isn't written down or version-stabilized, third parties can't reliably build compatible wasm commands, and changes to the patched libc / syscall surface risk silently breaking existing modules.

Naming TBD — this is the interface between the host/runtime and the guest wasm modules (the "guest ABI" / "wasm command ABI" / syscall surface). Part of this issue is settling on a name.

Ask

• Document the ABI: the exact contract a wasm module must satisfy to run as an agentOS command.
• Stabilize it: define a stability/versioning policy so guest modules and the runtime evolve compatibly.

Should cover

• Supported WASI subset + which functions are provided/stubbed/extended.
• secure-exec extensions / custom syscalls beyond WASI (networking, pty, process, sockets).
• The patched-wasi-libc surface (what patch-wasi-libc.sh adds/changes vs upstream).
• Command invocation contract: entry dispatch (header/magic number), argv[0] multicall, env, fd conventions, exit codes.
• How the sidecar/kernel presents fds / sockets / pty / child processes to the module.

Context

Surfaced during the registry { packageDir } migration: the C command build depends on a patched wasi-libc sysroot for networking (netdb.h), which highlighted that the host↔guest wasm contract is load-bearing but undocumented.