fix(tools): raise the open-file limit at startup + actionable fd-quota errors (#122)

[justrach]

What

• std.process.raiseFileDescriptorLimit() in main() before subcommand dispatch: lifts the soft NOFILE cap to the OS hard cap (Darwin: OPEN_MAX 10240 vs the 256 default). Zig 0.16.0 std ships this with correct Darwin clamping, so the fix is the one-liner discussed on the issue.
• tools.failure() special-cases ProcessFdQuotaExceeded with an actionable message (what it means, retry sequentially, ulimit -n 4096) instead of the bare error name.
• The background-job spawn path no longer suggests "run it in the foreground instead" for an fd-quota hit — backgrounding costs more fds, so that advice was actively wrong for this error.

Why

The audit on #122 disproved the FD-leak theory (graff's own FD count is flat at 11 across turns; 150 sequential bash spawns under ulimit -n 256 all succeed) — the failure mode is parallel tool/subagent/MCP fan-out pressure against the 256 default. Raising the limit at startup defuses it.

Verification (end-to-end A/B)

Scripted lmstudio-slot mock orders a bash: ulimit -n tool call through a real --json turn, parent shell capped at ulimit -n 256:

binary	child sees
this branch	10240
installed v0.0.200	256

zig build + zig build test clean.

Closes #122 (remaining items on that issue — fan-out caps — are follow-up material; the limit raise + error message were the actionable core).