Fix three shen-lua-only Prolog divergences (call/1, var?/1, query capacity)

[pyrex41]

urdr's four-port conformance spike (spikes/m1-prolog-portability) runs 112
Prolog probes on shen-go, shen-lua, shen-cl and shen-rust and compares the
bytes. Measured on today's pinned checkouts, 8 of 112 probes diverged and
all 8 were shen-lua-only. This PR takes that to 0 of 112 — all four ports
now byte-identical (sha256 46fd40e4a63ab3b8a0aa8b5c4a704fbbd812f1ef0cb2ca4da2291a3822f1b335).

The underlying cause of all three classes is that shen-lua does not run the
kernel's Prolog: it runs an independent native engine (prolog_engine.lua +
prolog_compile.lua). All three turned out to be surface bugs in that
engine, not structural divergence. No rewrite; ~50 lines changed.

D-1 — call/1, generic goal invocation

(call G) raised native call: goal is not a structure whenever the goal
arrived as a predicate argument rather than as a call/1 literal. That
removed \+, forall and any parameterised query driver.

The kernel spells a goal as a partial application: shen.function-calls
(prolog.shen) leaves a goal-shaped argument (F A1..Ak) as a Shen
application, so evaluating it yields a closure still wanting Bindings / Lock /
Key / Continuation, and (define call Call B L K C -> (Call B L K C)) just
supplies them. The native engine spells a goal as a structure and
dispatches on its head — E.g_call already expected (pred a1..ak).

Nothing ever built that structure. compile_term fell through to the
guard-lift branch, evaluated (F A1..Ak) as ordinary Shen, and imported the
resulting legacy CPS closure as an opaque atom, which E.g_call rejected.
New compile_goal_term emits the CONS chain for an application of a
registered prolog predicate that supplies exactly its term arguments — the
only shape call/1 can complete. Everything else still guard-lifts.

Side benefit: findall/3 inside a clause body took the same path and now
works natively too.

D-2 — var?/1

E.g_var takes the uniform native goal ABI (term, count, cont) — the ABI
test/engine_spec.lua:255 already pins. The clause compiler emitted
GVAR(x, k), so the continuation landed in the count parameter and cont
was nil. On the failing path g_var returns before touching cont, which
is why this hid: only a succeeding varhood test reached thawH(nil) and
crashed with attempt to call local 'h' (a nil value) — a Lua-level internal
error rather than a Shen-level failure.

D-3 — per-query variable capacity

shen.call-prolog allocates one absvector of (value shen.*prolog-memory*)
slots per query (macros.shen:179). Slot 0 holds the printer and slot 1 the
next-index ticket, so indices 2..N-1 are usable and shen.newpv dies once the
ticket reaches N. declarations.kl — byte-identical in all four ports'
checkouts — pins N at 1000. (The kernel sources also contain
(prolog-memory 1e4), but the shipped KL that every port actually loads does
not, so 1000 is the spec, and it is what all four ports report.)

shen-lua ignored the ceiling on both its engines, so a query that raises
everywhere else answered here:

• native — prolog_engine.lua's variable arena grew by doubling with no cap.
  query_begin now records var_base and re-reads the budget (nested queries
  get their own; (prolog-memory N) takes effect on the next query) and
  newvar raises past it. var_top - var_base is exactly the kernel's
  ticket - 2, because popvar already mirrors shen.gc's ticket decrement.
• compiled-KL CPS (SHEN_PROLOG_ENGINE=legacy, SHEN_PROLOG_NATIVE=off) —
  absvector is a Lua table and address-> is an unchecked store
  (prims.lua:343), so shen.nextticket wrote past the end and the vector
  silently grew. Checked in shen.newpv, which is exactly where the kernel's
  ceiling is, rather than bounds-checking absvector generally (the kernel
  uses out-of-range absvector reads deliberately elsewhere).

The ceiling lands on the same query depth as the other three ports, probe for
probe: 500 and 900 succeed; 1000, 1200, 1500 and 2000 raise.

Four-port probe results

probe	before (go / lua / cl / rust)	after
C9-naf-generic-true	failed / <error> / failed / failed	all failed
C10-naf-generic-false	holds / <error> / holds / holds	all holds
E1-var-unbound	unbound / <error> / unbound / unbound	all unbound
E7-fresh-var-in-result	unbound / <error> / unbound / unbound	all unbound
G4c-depth-1000	<error> / done / <error> / <error>	all <error>
G4d-depth-1500	<error> / done / <error> / <error>	all <error>
G5-depth-2000	<error> / done / <error> / <error>	all <error>
J3-over-smallest-ceiling	<error> / done / <error> / <error>	all <error>

Divergence count: 8 of 112 → 0 of 112.

Tests

test/prolog_semantics_spec.lua is new: 27 checks, every expectation
measured on shen-go, shen-cl and shen-rust and identical on all three. It
was committed failing first (8 of 22 red on main), then the fixes landed.
It also probes the legacy engine out of process; reverting the prims.lua
hunk turns that check red (verified).

                      main                 this branch
make test     540 pass, 0 fail        567 pass, 0 fail
              across 15 specs         across 16 specs
make certify  134 passed / 0 failed   134 passed / 0 failed
              100%                    100%

No performance regression: run-kernel-tests.lua user time 9.57s on main
vs 9.50s here; fib(32) unchanged (0.095-0.100s both).

Deliberately not done

• Not touched: the eval-order fix from fix: evaluate list literals / deep call chains left-to-right #49.
• (call G) where G is a builtin goal ((call (is X 1))) still has no
  native dispatch — E.g_call only looks up NP[name]. The kernel accepts it
  because everything is a closure there. No probe covers it and it does not
  appear in any test; left as a known gap rather than guessed at.
• No change to absvector / address-> bounds generally.
• No change to shen-lua's choice of an independent Prolog engine. The
  agreement across the other 104 probes is still coincidental rather than
  structural — nothing in the kernel constrains a reimplementation — and this
  PR does not change that argument. It only removes the cases where the
  coincidence had already broken.

🤖 Generated with Claude Code