fix(runtime): Node arg-validation errors on fs + assert.throws code/name matching (#2013, #2014)

[proggeramlug]

Summary

Addresses the cross-cutting Node error-validation parity theme surfaced by the #800 sweep after #1924 fixed assert.throws. Two coupled issues:

• assert.throws: object validator doesn't check error .code/.name/.message (follow-up to #1924) #2014 — assert.throws(fn, validator) accepted a wrong-code error as a pass.
• stdlib doesn't throw Node arg-validation errors (ERR_INVALID_ARG_TYPE/EBADF/...) on bad input — ~85 tests across fs/buffer/net/http/crypto/zlib/process #2013 — fs APIs returned sentinels instead of throwing Node's ERR_INVALID_ARG_TYPE / EBADF on bad input.

They're handled together because verifying #2013 honestly requires #2014's matcher to actually compare error codes.

#2014 — assert.throws object validator

• Error objects now hold user-assigned own properties. ErrorHeader is a fixed #[repr(C)] struct with no field-storage region, so err.code = "X" / err.errno = -2 / custom fields were silently dropped and read back as undefined. A per-error side table (keyed by the error pointer, owned-String for string values / raw bits for immediates — GC-safe) now backs these; the object setter routes GC_TYPE_ERROR sets to it, and the .code/.name/… getters check it first (so a user override also works).
• object_matcher_matches: dropped the over-lenient carve-out that treated a missing actual code/errno as a match — a wrong/absent code is now a mismatch, matching Node.
• expected_error_matches: a plain object validator ({ code: … }) now matches only via its own keys; it no longer falls through to the instanceof / builtin-constructor checks that could spuriously accept any error.

const e: any = new Error("x"); e.code = "ERR_A";
assert.throws(() => { throw e; }, { code: "ERR_B" });  // before: passed (bug) — now: throws ✓

#2013 — fs argument validation

New reusable fs::validate module:

• validate_path (path-only functions) → ERR_INVALID_ARG_TYPE (TypeError) on any non path-like input (string / Buffer / file: URL are accepted).
• validate_path_or_fd (readFileSync / writeFileSync) → treats a number as a file descriptor and throws EBADF for an unregistered/closed fd, otherwise ERR_INVALID_ARG_TYPE. fd validity is checked against Perry's synthetic FD_REGISTRY (fds start at 100), not the OS — an early fcntl-based version wrongly rejected valid Perry fds and broke the fd read/write tests; fixed.

Wired into accessSync, statSync, lstatSync, readdirSync, mkdirSync, unlinkSync, rmdirSync, readlinkSync, openSync, readFileSync, writeFileSync.

fs.readFileSync(123 as any);  // before: returned ""    — now: throws EBADF ✓
fs.accessSync(true as any);   // before: code=undefined — now: ERR_INVALID_ARG_TYPE ✓

Verification

• Byte-identical to Node v25 across the full fs validation matrix (path-only → ERR_INVALID_ARG_TYPE; readFile/writeFile number → EBADF, other bad types → ERR_INVALID_ARG_TYPE) and the assert.throws repro/positive/negative cases.
• No regressions in the fs or assert node-suites. Remaining failures are pre-existing and unrelated to this change: assert.rejects is unimplemented; deepStrictEqual Map/Set/cause gaps; CallTracker (removed in Node 20); cp symlink-deref; rmdirSync({recursive}) removal error.
• cargo fmt --all -- --check clean.

Follow-ups (not in scope here)

• The same validate_path helper extends naturally to the remaining fs functions and the other APIs in stdlib doesn't throw Node arg-validation errors (ERR_INVALID_ARG_TYPE/EBADF/...) on bad input — ~85 tests across fs/buffer/net/http/crypto/zlib/process #2013 (buffer / net / http / zlib / crypto / process).
• assert.rejects / assert.doesNotReject (async) is still unimplemented — would flip the 3 rejects node-suite tests; worth its own issue.