P5.2: emit_object() -> string query primitive

The compiler emits the sx object eagerly (the Zig driver, before the post-link
callback), so emit_object is a QUERY (not an action): it returns the path from
a new BuildConfig.object_path field main.zig forwards — no driver vtable. This
completes the build-pipeline QUERY primitives (emit_object / c_object_paths /
link_libraries); only link (the genuine action) remains for the vtable step.

Extended examples/1662 to also assert emit_object().len > 0. 703/0 both gates.

current/CHECKPOINT-COMPILER-API.md

@@ -94,11 +94,14 @@ with ONE welded mechanism. Branch: `reify` (off `master`). Update after every st
 > the call's result type (`ins.ty`). Legacy handlers bail loudly (VM-only by nature — post-link). Smoke test
 > `1662-platform-build-pipeline-queries` (AOT, C companion → 1 object): a post-link callback checks the VM-built
 > list is well-formed; build exit 0 ONLY if so (negative-probe verified: wrong count → "post-link callback
-> returned false", exit 1). **703/0 both gates.** **NEXT — P5.2b: `emit_object` + `link` (the ACTIONS).** These
-> are NOT data reads — in the end state the Zig driver stops auto-emitting/auto-linking and the sx driver calls
-> them, so they need the driver-restructuring (a callback vtable the host installs into the VM, since
-> `comptime_vm.zig` can't depend on `core`/`main`/`target`). `link` is fallible (`-> !`) — its failable return
-> shape is the new VM piece. Then P5.3 (`on_build` slot — invoke WITH the `BuildConfig` arg; needs a VM entry
+> returned false", exit 1). **`emit_object() -> string` ALSO landed** (a QUERY — the Zig driver emits eagerly, the
+> primitive returns `BuildConfig.object_path`; NO vtable). So all three QUERY primitives are done. **703/0 both
+> gates.** **NEXT — P5.2b: `link(...) -> !` (the one genuine ACTION).** In the end state the Zig driver stops
+> auto-linking and the sx driver calls `link`, so it needs the driver-restructuring (a callback vtable the host
+> installs into the VM, since `comptime_vm.zig` can't depend on `core`/`main`/`target`) + a List(string)-arg
+> READER (inverse of `makeStringList`) + the fallible `-> !` return shape (a `(value…, tag=0)` tuple, since `!T`
+> is a tuple — `makeOkFailable`). Build it tested via a post-link callback linking to a TEMP output (avoids
+> clobbering the real binary; the Zig driver still links until P5.4). Then P5.3 (`on_build` slot — invoke WITH the `BuildConfig` arg; needs a VM entry
 > that marshals args, the gap `invokeByFuncId` rejects today) · P5.4 (sx `default_build` + delete
 > `#compiler`/`compiler_call`/`compiler_hooks` + the S5a `build_options`/`set_post_link_callback`) — P5.4 kills
 > the 4 strict `compiler_call` bails (1609/1614/1615/1616).
@@ -429,7 +432,12 @@ when reached (sentinels or accessor fns; see the design doc Risks).
   `examples/1662-platform-build-pipeline-queries` (AOT + a 1-line C `#source` → exactly one C object): a post-link
   callback asserts `c_object_paths().len == 1`, `items[0].len > 0`, and iterates `link_libraries()` (liveness
   touch) — build exit 0 only if the VM-built list is well-formed. **Negative-probe verified** a real guard (forcing
-  `len != 2` → "post-link callback returned false", build exit 1). **No unit test for `makeStringList`** —
+  `len != 2` → "post-link callback returned false", build exit 1). **`emit_object() -> string` ALSO landed (same
+  step):** a QUERY, not an action — the compiler emits the object eagerly (the Zig driver, before the callback),
+  so the primitive just returns the path from a new `BuildConfig.object_path` field `main.zig` forwards (no
+  driver vtable needed). 1662's callback now also asserts `emit_object().len > 0`. So ALL THREE query primitives
+  (`emit_object`/`c_object_paths`/`link_libraries`) are done; only `link` (the genuine ACTION) remains. **No unit
+  test for `makeStringList`** —
   constructing a `List(string)` `TypeId` in the test harness needs generic instantiation; the corpus test
   exercises the real stdlib type end-to-end with a non-empty list + a negative guard instead. **`emit_object` +
   `link` (the ACTIONS) deferred to P5.2b** — they must replace the Zig driver's auto-emit/auto-link (not duplicate

current/PLAN-COMPILER-VM.md

@@ -509,10 +509,13 @@ The compiler's whole post-IR role: codegen → build the CLI-derived `BuildConfi
   serviced by `comptime_vm.callCompilerFn` over `BuildConfig` fields `main.zig` forwards; new VM `makeStringList`
   builds the `List(string)` in flat memory from the call's result type (`ins.ty` now threaded through
   `invoke`/`callCompilerFn`). Smoke test `1662-platform-build-pipeline-queries` (AOT + C companion). 703/0 both
-  gates. **P5.2b — the ACTIONS (`emit_object -> !string`, `link(...) -> !`, reuse `target.zig`):** still TODO —
-  they replace the Zig driver's auto-emit/auto-link, so they need the driver restructuring + a host-installed
-  callback vtable (`comptime_vm.zig` can't depend on `core`/`main`/`target`); `link`'s fallible `-> !` return is
-  the new VM shape.
+  gates. **`emit_object() -> string` is also DONE (2026-06-19)** as a QUERY (not an action): the Zig driver emits
+  the object eagerly, so the primitive just returns the path from `BuildConfig.object_path` (no vtable). So all
+  three QUERY primitives are done. **P5.2b — `link(...) -> !` (the one genuine ACTION):** still TODO — it replaces
+  the Zig driver's auto-link, so it needs the driver restructuring + a host-installed callback vtable
+  (`comptime_vm.zig` can't depend on `core`/`main`/`target`) + a `List(string)`-arg reader (inverse of
+  `makeStringList`) + the fallible `-> !` return (a `(value…, tag=0)` tuple, since `!T` is a tuple). Test it via a
+  post-link callback linking to a TEMP output (the Zig driver still links until P5.4).
 - **P5.3 — `on_build` slot:** a comptime-assignable compiler slot (GENERALIZES today's `post_link_callback_fn`:
   an assignable typed global with a stdlib default, vs a setter). `#run on_build = build;` captures the
   `FuncId`; the compiler invokes it post-codegen with the CLI-derived `BuildConfig`.