P5.2b: link() build-pipeline action on the VM via a host vtable

The one genuine action primitive: link(objects, output, libraries, frameworks,
flags, target) in library/modules/std/build.sx. Per the user decision to drop
fallibility from the build callback, link is plain VOID — a link failure bails
on the VM (hard build error), no -> ! / failable-tuple needed.

comptime_vm.zig can't depend on the driver (core/main/target), so link
dispatches through a new compiler_hooks.BuildHooks { ctx, link } vtable that
main.zig installs into BuildConfig.build_hooks before the post-link callback.
The driver side is main.LinkHooksCtx (unions explicit + CLI link flags, calls
target.link). New VM readers readStringList / readStringArg (inverse of
makeStringList) decode the List(string)/string args from flat memory.

Smoke test examples/1663-platform-build-pipeline-link (AOT): a post-link
callback re-links the build's own objects (c_object_paths + emit_object) into a
temp output via sx link — the relinked binary is a functional executable that
runs. Negative-probe verified (bad path -> ld fails -> ComptimeVmBail -> build
exit 1). The Zig driver still auto-links; removing that is P5.4.

704/0 both gates.

library/modules/std/build.sx

@@ -20,3 +20,10 @@ link_libraries :: () -> List(string) abi(.compiler);
 // eagerly; this returns its path (a query, not an action). The sx driver passes
 // it to `link` alongside the C objects.
 emit_object :: () -> string abi(.compiler);
+
+// Link `objects` into `output`, with the given libraries / frameworks / link
+// flags / target triple. The one genuine ACTION primitive — the compiler keeps
+// the proven linker (Option B); the sx driver orchestrates. Not fallible (the
+// build callback isn't): a link failure fails the build directly.
+link :: (objects: List(string), output: string, libraries: List(string),
+         frameworks: List(string), flags: List(string), target: string) abi(.compiler);