recognize zero-arg name() and name!() in every operand position

[danieljohnmorris]

Summary

Closes the routing-tsp persona friction at ilo_assessment_feedback.md:1564. SPEC.md:16 says zero-arg call is make-id() and SPEC.md:843 documents fetch!(), but the implementation only recognised the parens at statement head / RHS of =. Every operand-position use (call arg, HOF collection slot, loop subject, range bound) routed through parse_operand → parse_atom, where the Ident arm returned Expr::Ref immediately and then choked on the dangling (.

Two-token lookahead inside parse_atom's Ident arm, mirroring the existing block at parse_call_or_atom:1803-1814. Bare name still parses as Expr::Ref, so HOFs like fld max xs 0 are unchanged — only the explicit () triggers invocation. What you read is what runs.

Repro

Before this PR, on 4ef85d4:

xs>L n;[1 2 3]
f>n;len xs()

ILO-P009: expected expression, got RParen

Same failure for hd xs(), at xs() 0, map dbl xs(), @v xs(){...}. After this PR all five positions parse and produce the same values across --run-tree, --run-vm, and --run-cranelift.

What's in the diff

• c49c700 recognize name() and name!() zero-arg calls in operand position — the parser fix. ~30 lines in parse_atom, mirrors the existing statement-head lookahead. Both the bare name() form and the auto-unwrap name!() form are handled.
• f672ece test zero-arg call in operand position across positions and engines — five new parser unit tests (one per broken position plus a HOF-regression guard) and examples/zero-arg-call.ilo exercising the same scenarios across all three engines via the existing tests/examples_engines.rs harness.

Test plan

• cargo test --release --features cranelift green (parser + verifier + tree + VM + cranelift JIT/AOT + examples harness)
• All five zero_arg_* parser unit tests pass
• examples/zero-arg-call.ilo runs identically across --run-tree, --run-vm, --run-cranelift
• HOF fn-ref regression test confirms map dbl xs (no parens) still parses as Ref so HOFs are unaffected

Follow-ups

• @v map dbl xs() (HOF call in loop-subject position) is still rejected — parse_operand doesn't call-parse there. Separate pre-existing limitation. Workaround in the example: bind to a name first (ys=map dbl xs();@v ys{...}).
• Auto-call (invoke a fn-ref the moment it lands in a value-shaped context) was explicitly rejected during gate review: it breaks HOF semantics and violates "what you read is what runs."

[codecov]

Codecov Report

❌ Patch coverage is 90.00000% with 12 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/parser/mod.rs	90.00%	12 Missing ⚠️

📢 Thoughts on this report? Let us know!