fix(codemode): stop leaking undefined into tool arguments

[rekram1-node]

Closes the outbound-handling gap from interpreter-support.md (previously an unchecked item). Tool arguments now cross the boundary with JSON.stringify semantics instead of passing raw undefined through to tools.

Behavior

For tools.api.search({ q: undefined, limit: 0/0, items: [1, undefined, 2] }) the tool now receives:

{ limit: null, items: [1, null, 2] }   // q dropped, NaN -> null, undefined element -> null

• Object properties with undefined values are dropped, like JSON
• undefined array elements and sparse holes become null
• Non-finite numbers become null (pre-existing behavior, unchanged)
• A bare tools.t(undefined) still reaches schema decoding as undefined (matches JSON.stringify(undefined) being undefined)

The headline user-visible improvement: the ubiquitous { query: cond ? value : undefined } idiom now works against Effect schemas using optionalKey, which reject a present undefined value. Previously that call failed decoding; now the key is dropped before the schema runs — matching what any JSON-transported tool call would see.

Program results deliberately keep the stricter normalization (undefined -> null everywhere), as do console.table columns.

Implementation

copyOut(value, undefinedAsNull?: boolean) becomes copyOut(value, mode: "raw" | "nullify" | "json") in tool-runtime.ts. Tool invoke and built-in search args use "json"; execution results and console.table use "nullify" (the old true); errors.ts/json.ts keep "raw" (the old default) where native JSON.stringify already applies these semantics itself.

Testing

• Unit tests pin json/nullify/raw modes against real JSON.stringify behavior
• End-to-end tests pin what a render-only JSON-Schema tool receives (dropped key asserted via Object.hasOwn), sparse-hole densification, and the optionalKey acceptance change for both a user tool and the built-in search
• interpreter-support.md updated in the same PR; 911 tests pass from packages/codemode