nx_toolsapi_bodycap_gate.nx

nx_toolsapi_bodycap_gate.nx -- END-TO-END referee for the tools-API request-body fix (2026-08-23). THE DEFECT IT GUARDS: nx_tools_api_serve read a request with ONE sys_read of 64 KiB and handed the partial bytes to the edge; every tools/call above that answered 413, and the laptop wire rendered the 413 as a bare {} -- a whole-file source write read as "dropped" and nobody could say why. Behind it, the argv scratch in ta_mcp_call was a second 64 KiB constant that kept "what fit": a file content above 65535 bytes was written as its prefix with an OK receipt. HOW IT PROVES IT: forks the SUBJECT daemon (default: the STAGED ./nx_tools_api_serve.sov.elf.new; argv[1] `live` = the serving-root binary; any other argv[1] = an explicit elf path) with CWD = /tmp/<gate>/ carrying a fixture cap secret and a one-row allowlist (argecho, the estate's multi-arg witness organ), mints a cap for that secret in-process with the estate's own capt_issue, and drives REAL loopback POST /mcp tools/call requests whose "name" key comes LAST -- after the payload -- so a truncated body can never name the tool. T1 8 KB argv echoed whole (positive control: fits one read on the old and the new binary) T1b the 8 KB reply is BYTE-IDENTICAL to the LIVE daemon's reply on a second port (behaviour control) T2 63 KB argv echoed whole (the measured failing case: the request exceeds 65536 bytes on the wire) T3 120 KB argv echoed whole (over the old window, under TA_CAPTURE_CAP so the echo itself is not cut) T4 neg-control: a request declaring Content-Length above EDGE_REQ_MAX answers 413 naming the limit T5 no reply is the bare {} nor the old "64KiB edge limit" text T6 fixture reached the condition: the T2 request really was > 65536 bytes T7 the subject child is gone after the gate (its port refuses again) -- a probe that leaves a daemon is a second instance A free port is PROVEN free (connect refused) before the subject binds it. license_tier: ORIGINAL expect_exit: 0 GREEN | 1 RED | 3 SKIP