forth: inline primitive calls in colon-def body (skip forth-execute-word)

plans/forth-on-sx.md

@@ -98,7 +98,7 @@ Representation:
 - [x] Target: 100% Hayes Core (97% achieved — remaining 5 errors all in `GI5`'s multi-`WHILE`-per-`BEGIN` non-standard pattern, plus one stuck `dict-set!` chunk and 14 numeric-edge fails)
 
 ### Phase 6 — speed
-- [ ] Inline primitive calls during compile (skip dict lookup)
+- [x] Inline primitive calls during compile (skip dict lookup)
 - [ ] Tail-call optimise colon-def endings
 - [ ] JIT cooperation: mark compiled colon-defs as VM-eligible
 
@@ -106,6 +106,17 @@ Representation:
 
 _Newest first._
 
+- **Phase 6 — inline primitive calls (Hayes unchanged at 618/638).**
+  `forth-compile-call` now appends the looked-up word's body fn
+  directly to the colon-def body instead of wrapping it in
+  `(fn (s) (forth-execute-word s w))`. `forth-execute-word body`
+  reduces to `((get w "body") state)`, so the wrapper added an
+  extra closure + `get` per call op for no behavioural gain. Same
+  early-binding semantics: the body fn is captured at compile time,
+  so later redefinitions of the same name don't retroactively
+  change existing definitions. All 306 internal tests still green;
+  Hayes Core stays at 618/638. Pure optimisation.
+
 - **Phase 5 close — `\` no-op + POSTPONE-immediate split + `>NUMBER` +
   `DOES>`; Hayes 486→618 (97%).** Big closing-out iteration.
   Made `\` IMMEDIATE so `POSTPONE \` (Hayes' IFFLOORED/IFSYM gate)