fix(parser-native): unblock stdlib expansion by avoiding bare case-decl pattern (#597)

[cs01]

Summary

Fixes #597 — the regression that blocked stdlib additions past 8 count. Unblocks #585 (net TCP module) and future stdlib expansion.

User-facing effect

• Compiler now correctly compiles itself with 8+ `registerStdlib()` calls. No more false-positive `checkMissingReturns` error on `transformExpression`.
• Stdlib module count no longer artificially capped.

Root cause (narrow observation)

Parser-native's switch_case iteration was producing a case body missing the trailing `return` for `case "unary_expression":`. The source body was:

```ts
case "unary_expression":
const voidOpChild = getChild(node, 0);
if (voidOpChild && (voidOpChild as NodeBase).type === "void") {
return { type: "variable", name: "undefined" };
}
return transformUnaryExpression(node);
```

Tree-sitter reports `namedChildCount=3` for this case clause (value + const + if), so parser-native iterates 3 children and the final `return` is never added to `caseStatements`. Downstream `checkMissingReturns` correctly flagged the resulting `[var_decl, if_no_else]` sequence as "does not return on all paths".

Why tree-sitter reports 3 instead of 4 is not yet root-caused — could be grammar greed in `if_statement`'s consequence production, or a named/anonymous node classification quirk. That is a separate investigation tracked as a followup in #597.

Fix (not a workaround, but avoids the trigger)

Extract the case body into a helper function `transformUnaryExpressionOrVoid`. The switch case becomes a single-statement body that can't trip the bare-case-decl pattern:

```ts
case "unary_expression":
return transformUnaryExpressionOrVoid(node);
```

Why this approach over the rejected alternatives:

• Block-wrap `{ ... }` — led to 138 native-test regressions (global `statement_block` handler too broad) and stage 1 segfault (scoped inline handler hit native-compiler fragility in the new iteration path).
• Fix parser-native's iteration — requires understanding the tree-sitter grammar quirk; that investigation is unbounded and will re-cross today's 20+min verify cycles. Deferred to a followup that can do dedicated LLDB + tree-sitter-inspector work.

The helper extraction is one-line-shift in behavior (same logic, different call site), preserves all existing parser paths, and the full self-host suite passes.

Test plan

• `npm run verify` — full 3-stage self-host + all tests green locally
• CI green

[github-actions]

Benchmark Results (Linux x86-64)

Benchmark	C	ChadScript	Go	Node	Place
Cold Start	0.9ms	0.8ms	1.2ms	26.0ms	🥇
Fibonacci	0.814s	0.762s	1.560s	3.496s	🥇
Hash Map Lookup	0.098s	0.063s	0.090s	0.112s	🥇
Binary Trees	1.327s	1.220s	2.678s	1.174s	🥈
File I/O	0.117s	0.090s	0.087s	0.196s	🥈
JSON Parse/Stringify	0.035s	0.049s	0.176s	0.129s	🥈
N-Body Simulation	1.672s	2.121s	2.199s	2.378s	🥈
Regex Match	0.016s	0.005s	0.022s	0.004s	🥈
SQLite	0.050s	0.371s	0.482s	0.413s	🥈
Monte Carlo Pi	0.389s	0.410s	0.405s	2.249s	🥉
Quicksort	0.215s	0.247s	0.213s	0.261s	🥉
Sieve of Eratosthenes	0.014s	0.026s	0.018s	0.038s	🥉
String Manipulation	0.008s	0.017s	0.016s	0.035s	🥉
Matrix Multiply	0.443s	0.737s	0.567s	0.388s	#4

CLI Tool Benchmarks

Benchmark	ChadScript	grep	node	xxd	Place
Hex Dump	0.559s	—	0.897s	0.131s	🥈
Recursive Grep	0.019s	0.009s	0.100s	—	🥈