P5.3: on_build(cb) build-callback registrar; callback takes BuildOptions

Per user design: on_build(build) is the build-callback registrar (a free fn),
generalizing set_post_link_callback — the callback is (opt: BuildOptions) ->
bool and the compiler invokes it post-codegen WITH the BuildOptions handle.

- VM: callCompilerFn 'on_build' arm + legacy handleOnBuild, both set
  post_link_callback_fn + a new BuildConfig.post_link_takes_options flag.
- comptime_vm: runEntry refactored to runEntryArgs(extra) (implicit ctx +
  explicit args); new public runBuildCallback(..., pass_options) passes the
  opaque BuildOptions handle (one word) after the ctx. The fat-config
  marshaling fear is moot — the handle is a single null-sentinel word.
- core.invokeByFuncId/invokeByName take pass_options (was an unused args
  slice); main.zig passes comp.getPostLinkTakesOptions().
- build.sx: on_build decl (set_post_link_callback kept for now).

Smoke test examples/1664-platform-on-build-callback (AOT): #run on_build(build)
with build :: (opt: BuildOptions) -> bool; the callback is invoked with the
handle arg (runEntryArgs param-count match) and runs the primitives.

Benign .ir churn (37 snapshots: type table +1 for the on_build fn type +
global renumber; behavior identical). 705/0 both gates.

src/ir/compiler_hooks.zig

@@ -33,6 +33,11 @@ pub const BuildConfig = struct {
     /// and invokes this function with no args. A `false` return is
     /// treated as a build failure.
     post_link_callback_fn: ?FuncId = null,
+    /// True when the post-link callback was registered via `on_build(cb)` (the
+    /// Phase 5 form, `cb: (opt: BuildOptions) -> bool`) rather than the legacy
+    /// `set_post_link_callback(cb)` (`cb: () -> bool`). When set, the compiler
+    /// invokes the callback with the opaque `BuildOptions` handle as its arg.
+    post_link_takes_options: bool = false,
     /// Alternative to `post_link_callback_fn`: the qualified name of
     /// a module whose `bundle_main` function should be called
     /// post-link.