#2701 gfx1150 (Radeon 890M): confirmed build+run, isystem build fix, --expert-cache auto UMA pitfall

Description

## Summary

**Confirmed: a second gfx1150 (Radeon 890M) machine builds Strata clean, passes 64/64 meaningful ctest cases, and
serves correct chat completions end-to-end** — IQ3_XXS + MTP, extending the report in `docs/AMD_HIP.md` #1217. This
isn't just "it technically runs": below is a build fix for a header-shadowing bug that can silently corrupt the HIP
compat shim, and a reproducible `--expert-cache auto` pitfall on unified-memory AMD APUs that's undocumented for
non-"budget" model families — everything needed to get a Strix Point box running the same way.

Full write-up, raw benchmark JSON, and the sanitized config: **https://gist.github.com/Influx934Threads/493b031121ee940570aff8561e5e49c4**

## Hardware/software

AMD Ryzen AI 9 HX 370 (Radeon 890M, gfx1150), 92 GiB RAM, Debian 13, TheRock ROCm 7.14.1 built isolated for
`gfx1150` only, Strata v0.1.44.1 (`296b59d`). `setup.sh` refuses this chip outright, so the pack build, MTP draft
layer, and server config were all done by hand with `tools/iq_pack.py` / `tools/mtp_fetch.py` / `tools/mtp_pack.py` /
`tools/mtp_rt.py`, reverse-engineering what `setup.py` would have generated.

## 1. Build fix: stale system HIP headers can win over the isolated SDK

On a distro with both a system HIP/ROCm package (Debian/Ubuntu ship HIP 5.x at `/usr/include/hip/`) and a separate
isolated ROCm/TheRock prefix, clang passes `--rocm-path`'s include dir with `-idirafter` (lowest priority) — so the
*older* system header can win, reporting `HIP_VERSION_MAJOR 5`. Strata's compat shim branches on exactly that
(`#if HIP_VERSION_MAJOR < 7`), so the build silently takes the wrong code path with no error. Fix: an explicit
`-isystem $SDK/include` ahead of `--rocm-path` in `CMAKE_HIP_FLAGS` (full command in the gist). ctest: 64/64
meaningful tests pass after the fix.

## 2. `--expert-cache auto` can OOM a UMA GPU — gap in setup.py's existing RAM-safety logic

`auto` sizes the GPU-side expert cache from RAM that's free *after* this model's ~40 GiB resident expert arena is
already loaded — fine on a discrete GPU (cache lives in VRAM), but on a UMA APU that arena and the "free RAM" figure
share the same pool, and the sizer doesn't discount for it. The engine does print a warning, but not a refusal; it
OOM-killed both this process and an unrelated already-running llama.cpp service here. `setup.py`'s own
`uma_expert_cache()` RAM-budget logic exists for this exact shape of bug, but only applies to Unsloth "budget"-family
models by its model table — IQ3_XXS has no `"budget"` flag, so that protection doesn't engage for it. Fix used here:
an explicit `--expert-cache 8192` (~17.8 GiB) instead of `auto`. Engine log excerpt and full explanation in the gist.

## 3. Numbers

Warm decode 23.1-24.8 tok/s, 95-98% MTP draft acceptance (`--spec 4 --spec-min-p 0.5`), deterministic sampling,
thinking disabled. Faster than the one existing gfx1150 data point in the docs (15-19 tok/s, no MTP breakdown) — not
a controlled A/B, just a second machine's numbers. Full table and raw JSON responses in the gist.

## Worth the few extra lines in setup.sh to support gfx1150 natively?

With two independent machines now confirming a correct build and correct output on gfx1150 (#1217 and this one),
and the kernel guards + hipBLASLt table already shipped, this looks like a small, bounded change to let
`setup.sh --backend hip` accept it (even kept unvalidated) instead of refusing outright. Happy to test a patch
against this hardware, or to fold this into `AMD_HIP.md` myself if that's preferred — just say which.