Fix optional-access edge cases, predicate error display, MinInt64, and compile-time call-target checks

[myzie]

A review pass over the repo turned up a handful of real bugs plus two stale spec claims. All are fixed here; everything is covered by new regression tests, and go test -race ./..., go vet, and short runs of every fuzz target pass.

Bugs fixed

1. Optional access (?. / ?[) declined or mangled valid receivers

The LHS walker in internal/optaccess had several gaps relative to the non-optional operators:

Expression	Before	After
[1, 2, 3]?[0]	compile error (illegal character '?')	1
{"a": 1}?.a	compile error leaking the sentinel (expected 'EOF', found __try_select__)	1
map(xs, it*2)?[0]	compile error (LHS chopped at the paren)	works
if(true, [1], [2])?[0]	compile error	works
a?.map, a?.if	compile error (while a.map works)	works

The walker now handles brace-closed primaries (bare object literals), bracket pairs that open the input, and the map/if keyword tokens that expr accepts as call targets and selector links. Rewrites whose LHS would be empty are declined outright so malformed input gets the parser's plain ? diagnostic instead of garbage sentinel source.

2. Predicate error messages leaked internal sentinels

formatPredicate only mapped __expr_map__ back to map, via a string ReplaceAll. So:

• filter(xs, if(it,1,2) > "x") reported `__expr_if__(it, 1, 2) > "x"`
• filter(xs, it?.name) reported `__try_select__(it, "name")`
• a string literal containing __expr_map__ was corrupted to "map" in the message
• JSON-style literals printed as []any{...} / map[string]any{...}

The fix replaces the string substitution with an AST-level display transform (on a copy — the shared tree is never mutated): keyword sentinels recover their names, optional-access calls print as recv?.field / recv?[idx], and composite literals print in the bare JSON style users type.

3. -9223372036854775808 (MinInt64) was unrepresentable

The parser produces unary-minus around bare digits that overflow int64 on their own, so the most negative integer failed at Run time. The fold pass now reads the negation and literal as a single signed parse (-0x8000000000000000 works too); one past MinInt64 still errors.

4. Unsupported call targets surfaced only at Run time

fns[0](), (f)(x), f()(x), and a?.b() compiled fine and then failed every Run with unsupported call target *ast.IndexExpr. They are now rejected at Compile time (continuing the direction of #15), and a?.b() gets a tailored message — cannot call the result of optional access (a?.b()) — instead of leaking the sentinel call. The runtime rejection stays as defense in depth. Spec updated.

5. Stale spec/llms.txt: integer overflow does not wrap

docs/reference/spec.md and llms.txt both claimed integer overflow "wraps (matching Go)", but the implementation has checked +/-/* and rejects -MinInt64 and MinInt64 / -1 with ErrEvaluate. Docs now describe the implemented (safer) behavior, and the previously tolerant adversarial overflow tests now pin it.

Noted but deliberately not changed

• Registered functions that panic propagate the panic (methods recover runtime errors). The sandboxing guide explicitly says not to register panicking functions, so this stays a documented contract.
• Generalizing call targets to arbitrary callable-valued expressions (e.g. fns[0](x)) would be a language-surface decision; this PR keeps the documented ident/selector rule and just moves the failure to Compile time.

https://claude.ai/code/session_01V9oqpXChcB6zJFr6yw956M

---

Generated by Claude Code