`quilon build` fails after the README build: libquilon_rt.a is never uplifted to target/release

[assapir]

Repro

Fresh clone, following the README exactly:

cargo build --release
./target/release/quilon build examples/hello_world.ql -o /tmp/hello

🔨 Building: examples/hello_world.ql
❌ Build error: libquilon_rt.a not found next to the quilon binary
   (/home/assaf/code/quilon/target/release). Build it with `cargo build`.

quilon run is fine — the JIT resolves the intrinsics from the rlib, and examples/hello_world.ql exits 42 as it should. Only the AOT path is affected.

Cause

src/build.rs::runtime_lib_dir() looks for libquilon_rt.a next to the quilon binary. When quilon-rt is built as a dependency of quilon, cargo emits the staticlib into deps/ with a hash and does not uplift it:

target/release/deps/libquilon_rt-fd332413d5b6d322.a   # 23 MB, exists
target/release/libquilon_rt.a                          # not created

Measured on this checkout:

command	uplifts target/release/libquilon_rt.a?
cargo build --release	no
cargo build --release --all-targets	no
cargo build --release -p quilon-rt	yes

Why CI doesn't catch it

The parity gate builds the archive itself rather than relying on the normal build — tests/examples_test.rs:120-152 compiles a fresh libquilon_rt.a and copies it next to the quilon binary before running the JIT/AOT comparison:

/// Ensure a FRESH `libquilon_rt.a` sits next to the `quilon` binary — `quilon build`
...
std::fs::copy(&fresh, bin_dir.join("libquilon_rt.a"))
    .expect("copy fresh libquilon_rt.a next to the quilon binary");

So the suite passes while the documented flow fails. Nothing in CI runs the README's two commands in order.

Possible fixes

1. README — document cargo build --release -p quilon-rt alongside cargo build --release. Smallest change, leaves the trap in place for anyone who forgets.
2. runtime_lib_dir() fallback — if libquilon_rt.a isn't next to the binary, glob deps/libquilon_rt-*.a and use the newest. Makes the documented flow work as written.
3. A cargo alias or xtask that builds both and does the copy, so the test helper and the user path share one mechanism.

I'd lean on 2, with 1 as a one-line addition — the error message is good, but it names a command (cargo build) that doesn't actually fix the problem.

Environment

• Raspberry Pi 5, aarch64, Arch Linux
• rustc 1.95.0, cargo 1.95
• LLVM 22.1.8, libgc 8.2.12
• HEAD = 9b5d905 (M3: Closures)

Unrelated but noticed while reproducing: with clang absent, the default linker fails with a bare No such file or directory (os error 2). --linker gcc works. Might be worth naming the missing binary in that error.