fix(runtime): extend fs::validate to fsync/fdatasync/fchown/lchown/lchmod/copyFile/write/writev (#2013)

[proggeramlug]

Summary

Extends the fs::validate helpers from #2035 to the rest-of-fs slice
of #2013 — the 27 assert.throws-style tests the issue update flagged
as still falling through:

API	Validation
fsyncSync / fdatasyncSync	fd type / range
fchownSync	fd, uid, gid (TypeError + RangeError per Node)
lchownSync	path-type, uid, gid
lchmodSync	path-type (mode validation deferred — see ordering note)
copyFileSync (+ async)	src/dest path-type, mode (TypeError on string, RangeError on out-of-range int)
writeSync family	fd
writevSync	fd, only when the buffers array is non-empty
exists (callback)	callback-must-be-function
lchown / lchmod async	same as their sync siblings + callback

New validators in fs::validate

• validate_fd(value) — TypeError for non-number, RangeError for NaN/Infinity/non-integer/out-of-range. Matches Node's validateInt32(fd, 'fd', 0).
• validate_int32(value, name, min, max) — reused for uid / gid / mode where Node validates a bounded integer.
• validate_function(name, value) — TypeError if the value isn't a Perry closure (via the existing extract_closure_ptr helper). Mirrors Node's validateFunction.

Range errors are surfaced through js_rangeerror_new and registered in the per-error side table from #2035 so err.code === 'ERR_OUT_OF_RANGE' round-trips correctly.

Deliberate scope limits

• lchmodSync mode range: Node opens the path first, so a bad mode on a non-existent path surfaces ENOENT before mode validation fires. Validating mode here in Perry would diverge from Node's ordering. The mode-on-existing-path validation is a separate follow-up paired with proper ENOENT propagation.
• writevSync empty buffers: Node skips fd validation when the buffers array is empty (returns 0 without touching the fd). Perry now gates fd validation on array.length > 0 to match.
• existsSync is unchanged — it never throws on bad input under Node and Perry already returns false via decode_path_value.
• Callback-required cases for fsync/fdatasync/fchown/copyFile aren't validated at the top of the callback wrapper — those already dispatch into the sync impl which now validates fd, so an assert.throws(() => fs.fsync(input)) with bad input throws regardless. Required-callback-on-valid-input is left for the next slice.

Verification

• Added test-parity/node-suite/fs/sync/arg-validation.ts — byte-identical to node --experimental-strip-types across 27 cases covering fd type/range, path-type, uid/gid type/range, copyFile src/dest/mode, write/writev fd, and the writev empty-array no-throw contract.
• No regressions in the rest of node-suite/fs (filehandle path still uses real fds; lchmodSync mode pass-through unchanged).
• cargo fmt --all -- --check clean.

Follow-ups (still in #2013)

• lchmodSync / lchownSync mode + range validation on existing paths (paired with ENOENT propagation).
• Required-callback validation on fsync/fdatasync/fchown async wrappers.
• buffer (10), net (10), zlib (10), http (9), process (8), crypto (7), url (2), timers (1) — same pattern, applied per-crate.