P5.6 (macOS): default_pipeline drives bundling; fix issue 0125 (array-format blowup)

build.sx now `#import`s the sx bundler and `default_pipeline` delegates to its
`bundle_main` when a bundle was requested (emit + link, then wrap the binary into
the `.app`/`.apk`); otherwise it just emit+links via the shared `emit_and_link`
core. The Zig `--bundle`/`post_link_module` dispatch shim is removed — the CLI
bundle flags only feed `BuildConfig`, and `default_pipeline` branches on
`bundle_path()`. Validated end-to-end on macOS: `sx build --bundle App.app
--bundle-id … foo.sx` on a plain program AND auto-bundle from `set_bundle_path`
both produce a valid signed `.app` (correct `Contents/MacOS/` layout, Info.plist,
passes `codesign`, binary runs). Also fixed a pre-existing host-build bug:
target_triple was left empty for host builds → `is_macos()` false → wrong flat
layout; main.zig now exposes the host triple when `--target` is absent.

bundle_main no longer re-calls `build_options()` (the handle is already its `opts`
param).

Fix issue 0125 (root cause): the type-match dispatcher unboxed each interned array
tag to the concrete array type — a whole-array load — and passed it to
`array_to_string` by value, which LLVM scalarized into one SelectionDAG node per
element (~12s / segfault at [65536]u8). The bundler's `format("…{}…")` instantiates
`any_to_string`, so importing it into the prelude surfaced 0125 for any large-array
program. Fix (route 1): `any_to_string`'s `case array:` arm calls `slice_to_string`,
and `lowerRuntimeDispatchCall` detects an ARRAY tag bound to a SLICE param and builds
a `{ptr,len}` slice VIEW of the payload pointer (`unbox_any → [*]elem` is an
int-to-ptr with NO load, paired with the array length) instead of loading the array.
Output is byte-identical (`[a, b, c]`). Pinned as
examples/0056-basic-large-array-format-no-blowup.sx; 0055 drops 12s → 0.2s.

37 `.ir` snapshots regenerated (build.sx now pulls in the bundler's types + the
array-format lowering changed); verified `.ir`-only, zero behavior-stream diffs.
705/0 both gates.

examples/0056-basic-large-array-format-no-blowup.sx

@@ -0,0 +1,27 @@
+// Interning a large (~64KB) array type and using `{}` formatting elsewhere must
+// NOT scalarize into an O(N) SelectionDAG (which crashed `sx build` / made
+// `sx run` take ~12s). The array Any-unbox formats via a SLICE VIEW of its
+// storage — no whole-array load.
+//
+// Regression (issue 0125): `any_to_string`'s `case array:` arm used to do
+// `array_to_string(cast(type) val)`, loading the whole [65536]u8 by value and
+// reading each element off the loaded aggregate. Now the dispatcher builds a
+// `{ptr,len}` slice view of the payload pointer and formats that — output is
+// identical (`[a, b, c]`), and a large unrelated array type costs nothing.
+
+#import "modules/std.sx";
+
+f :: () {
+    buf : [65536]u8 = ---;
+    buf[0] = 65; // 'A'
+    out(string.{ ptr = @buf[0], len = 1 });
+    out("\n");
+}
+
+main :: () -> i32 {
+    f();
+    print("{}\n", 5);                 // an int format — unaffected by the big array
+    small : [3]i64 = .[7, 8, 9];
+    print("{}\n", small);             // array format still renders the element list
+    return 0;
+}

examples/expected/0056-basic-large-array-format-no-blowup.exit

@@ -0,0 +1 @@
+0

examples/expected/0056-basic-large-array-format-no-blowup.stderr

@@ -0,0 +1 @@
+

examples/expected/0056-basic-large-array-format-no-blowup.stdout

@@ -0,0 +1,3 @@
+A
+5
+[7, 8, 9]