fix(factory): route JSON validation error through commander writeErr on Node.js 22

[levontumanyan]

What

Routes the JSON-format input validation error through commander's configured writeErr instead of writing directly to process.stderr.write.

Why this broke

PR #410 upgraded commander v14 → v15. Commander 15 is ESM-only. The test suite runs via tsx, which compiles TypeScript to CommonJS, so commander is loaded via a dynamic await import('commander') — a CJS→ESM boundary.

On Node.js 22, this boundary causes global stream patches (process.stderr.write = ...) to become unreliable across calls: the second test in the schema input - JSON format error output suite consistently got an empty out buffer (→ parsed = null → TypeError: Cannot read properties of null), while the first test passed fine. Node.js 24/25 handle the CJS/ESM interop differently and don't exhibit this.

This is what was blocking the release PR #395 from merging.

The fix

- process.stderr.write(JSON.stringify({ error: { ... } }) + '\n')
+ const writeErr = cmd.configureOutput().writeErr ?? ((s: string) => process.stderr.write(s))
+ writeErr(JSON.stringify({ error: { ... } }) + '\n')

cmd.configureOutput().writeErr is the public commander API for error output — it's already what the test captures via cmd.configureOutput({ writeErr: (s) => { out += s } }). Routing through it avoids the global patch entirely and is consistent with how commander itself handles all other error output internally.

Scope — follow-up needed?

This fixes only the one failing test (factory.ts:574 — input validation error in --json mode). There are ~10 other process.stdout/stderr.write calls in factory.ts inside action handlers (lines 516, 589, 591, 601, 603, 615, 619, 623, 631, 633, 635) that use the same pattern. They aren't currently causing CI failures — either because their tests run first in their scope, capture stdout only, or use configureOutput directly. But they carry the same theoretical risk on Node.js 22.

Reviewer: is a follow-up PR to migrate those remaining calls worth doing for consistency and future-proofing, or is fixing just the failing test sufficient?