LLVM 21 → 22: build stack upgrade + codegen/runtime fixes

[fxdv]

What

Upgrades the bootstrap build stack from LLVM 21 → LLVM 22 so the compiler builds with current toolchains (Homebrew now ships llvm@22, not llvm@21), and fixes a set of pre-existing codegen/runtime bugs that the new build surfaces (it runs code the old build rejected at validation).

Commits

1. LLVM 21 → 22: bump inkwell/llvm-sys, update CI, port runtime

   • inkwell 0.9.0 (llvm22-1) + llvm-sys 221.0.0
   • bootstrap-branch CI (ci/release/benchmarks): apt llvm-22, LLVM_SYS_221_PREFIX
   • wasm-ld-21 → wasm-ld-22; inkwell 0.9 API adaptations
   • JIT function mapping rebuilt as tables + a defensive pass that also maps LLVM's .N-suffixed declaration variants (duplicates were auto-suffixed and missed by by-name mapping → NULL externs)
   • Linux-gated reactor/wakers; new src/runtime/jit_stubs.rs

2. Fix codegen/runtime bugs surfaced by the LLVM 22 build — all pre-existing on the bootstrap tip:

   • Duplicate std declarations (codegen.rs): the prelude declared 9 runtime symbols twice with conflicting arities (e.g. array_new 2-arg vs the 1-arg real impl). LLVM auto-suffixes duplicates (array_new.10); call sites bound to the numbered copy, which the JIT never maps → NULL → segfault. Now a single canonical declaration set.
   • str_* method resolution (codegen.rs): MIR names method calls with an overload suffix (str_trim_1); the host_ mapping ran on the suffixed name → non-existent host_str_trim_1 → NULL. New host_candidate_for() strips the trailing _<digits> first (also fixes len_str_2 → host_str_len).
   • Neutered array_new (array.rs): returned 0x0BADF00D + a debug print since v0.3.88 (stale autonomous-agent landmine); the real implementation (header + data alloc, canary, 0xCD fill) is restored.
   • Array-like method dispatch (gen.rs): push/append/len/count/get/set only handled DynamicArray receivers; [u8] slices and annotated arrays fell through to an unmapped bare name. Now covers Array | Slice | DynamicArray.
   • use of inline modules (resolver.rs): use math::add; for an inline mod math failed file resolution (W2002), leaving unqualified calls bound to a dead extern while the real body sat registered as math::add. The registered module::item is now aliased under the plain import name (same treatment file imports get). Works when the mod precedes the use (single-pass registration — noted in a comment).

Validation

Full .z suite A/B — this branch vs the shipped May 8 prebuilt binary (bin/zetac-macos-arm64), 477-file bootstrap suite, 30 s per-file timeout:

	PASS	NOMAIN	ERR	CRASH	HANG
May prebuilt (LLVM 21)	240	101	98	37	1
This PR (LLVM 22)	314	101	23	35	3

Main-branch 785-file suite: PASS 492 → 501, CRASH 94 → 85.

cargo fmt --check ✓ · cargo clippy --workspace --all-targets: 0 warnings ✓ · cargo test: 114/114 ✓
Builds on macOS arm64 with Homebrew llvm@22 (LLVM_SYS_221_PREFIX=/opt/homebrew/opt/llvm@22).

Known pre-existing issues (not caused by, nor fixed in, this PR)

• [dynamic] non-i64 index-access cluster (~16 sieve/murphy/benchmark files, e.g. tests/primezeta/test_sieve.z): index access on [dynamic]u8-style arrays lowers to raw getelementptr i64 loads/stores (wrong element width, no bounds check), and array_push does not grow a full array. These files previously never ran (validation rejected the array_new call, which is why they were ERR before); now they execute and read/write out of bounds — non-deterministic garbage results, occasional crash/hang depending on heap layout. Suggests a follow-up PR: lower index access through array_get/array_set using the declared element width, and make array_push grow.
• || parser regression: a function whose body contains || (e.g. a && b || !a) is silently dropped from the file (No main function found. Available: []); the same file works on the May binary. Tip parser issue; follow-up PR.
• Pre-existing crash set (21 files): crash identically on the May binary (spot-checked — same signal and first diagnostic on both builds).
• Self-host: zeta_src/main.z hits E4001 on both the May binary and this build (a raw string containing fn main derails parsing) — pre-existing.
• AOT linking needs zeta_runtime_c.o in the working directory (missing in a fresh checkout) — pre-existing; JIT execution is unaffected.

Follow-up (separate PR — a PR can only target one branch)

Main-branch workflows (ci, build-macos, build-binaries, release, benchmarks) all check out bootstrap and install LLVM 21; once this merges they need the same 21 → 22 bump. Related: main-branch build-macos.yml has been failing silently since the May 8 reactor merge (stale bin/ artifacts persist, and bin/zetac-macos-x64 is actually a Linux ELF).

[fxdv]

@murphsicles could you take a look when you have a moment? Two commits: (1) the LLVM 21→22 bump — inkwell llvm22-1 / llvm-sys 221, bootstrap CI, runtime port; (2) five pre-existing codegen/runtime fixes the new build surfaces (details in the description).

Note the bootstrap ci.yml doesn't trigger on PRs, so there are no checks here — the full-suite A/B numbers (240→314 PASS on the 477-file suite) and the known pre-existing issue list are in the description. Happy to split or adjust scope if you'd prefer.