installer: add pipe-safe --cpu / --vulkan flags for the llama.cpp backend (#7213)

[LeoBorcherding]

Problem

Forcing the CPU llama.cpp build doesn't work through the documented pipe:

UNSLOTH_LLAMA_CPP_BACKEND=cpu curl -fsSL https://unsloth.ai/install.sh | sh

The VAR=x prefix binds to curl, not the sh on the other side of the pipe, so
setup.sh reads the backend as unset, auto-detects the reporter's Intel iGPU, and
installs the Vulkan prebuilt (their UNSLOTH_PREBUILT_INFO.json: force_cpu: false,
a vulkan asset). The selection logic is correct: when the var actually reaches the
environment, setup.sh forwards --force-cpu and the install honours it. It just
never arrives. install.sh already documents this same pipe footgun for --no-torch
and solves it with a flag; there was none for the backend.

Fix

Add --cpu / --vulkan flags to install.sh and install.ps1, mirroring
--no-torch, that export UNSLOTH_LLAMA_CPP_BACKEND so it survives the pipe:

curl -fsSL https://unsloth.ai/install.sh | sh -s -- --cpu

Also forwarded across the WSL reroute, and the header now shows the correct
post-pipe env form. No change to backend selection, prebuilt resolution, or setup.
An explicit flag wins over an inherited env var, matching the other flags.

Tests

New tests/sh/test_llama_backend_flag.sh (11 checks) pins the flag to env-var
wiring in both installers and the WSL forward; existing test_install_pipe_safety.sh
and test_with_llama_cpp_dir_flag.sh still pass; both installers parse clean.

Not verified end to end (no Intel-iGPU host here). The reporter can confirm with
... | sh -s -- --cpu, then check force_cpu: true and a cpu asset in the marker.

[LeoBorcherding]

@codex review

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[LeoBorcherding]

Overall this is a clean, well-scoped fix and the root cause (the VAR=x curl | sh binding) is correct. The env-var wiring, WSL-reroute forward, and doc fix all look right. One medium item on the PowerShell side, plus two minor ones.

1. (medium) install.ps1 leaks $env:UNSLOTH_LLAMA_CPP_BACKEND into the caller's session on the iex path

irm ... | iex runs in the current PowerShell session, so $env:UNSLOTH_LLAMA_CPP_BACKEND = $LlamaCppBackendFlag (install.ps1:176) persists after the install finishes. A second install in the same session would then silently reuse the backend even with no --cpu passed.

This is the exact hazard the script already guards elsewhere: UNSLOTH_LOCAL_LLAMA_CPP_DIR (2810) is cleared with Remove-Item Env: after the setup run (2832), same for UNSLOTH_STUDIO_HOME (2801) and STUDIO_LOCAL_REPO (2786). Suggest matching that pattern: set the env var next to the setup.ps1 invocation and Remove-Item Env:UNSLOTH_LLAMA_CPP_BACKEND -ErrorAction SilentlyContinue after, or save/restore any prior value.

Counterpoint: $env:UNSLOTH_VERBOSE at 181 also leaks and isn't cleaned, so there's some precedent to not bother, but a sticky backend is closer to the local-dir case than to a debug toggle. install.sh isn't affected: the piped sh is a subshell, so its export dies on exit.

2. (minor) --cpu and --vulkan together resolve silently to last-wins

Passing both just takes whichever the arg loop sees last, with no signal. setup.sh already warns on an unrecognized backend value, so a short "both set, using X" warning here would be consistent. Low priority since it's user error.

3. (nit) the ps1 assertions in the new test pin exact interior whitespace

'"--cpu" { $LlamaCppBackendFlag = "cpu" }' will break on a harmless realignment of install.ps1. The sibling test_with_llama_cpp_dir_flag.sh matches just the flag token; suggest loosening to the semantic substring (e.g. $LlamaCppBackendFlag = "cpu").

---

Nice touches: the WSL-reroute forward is correctly ordered after the flag to export step so it picks up both the flag and a user-set env var, and the header comment calling out the before-vs-after-pipe footgun is exactly the confusion that opened #7213.