[mgehre-amd]

The pinned Magpie was e6833b8 ("Bump Magpie version to 0.2.0", 2026-07-22), whose scripts/benchmark/ holds MI300X and MI355X runners only. Strix Halo runners arrive seven weeks later in d4de63d ("Add Strix Halo/GFX1151 Support", #90, 2026-09-11), which adds vllm_radeon8060s.sh and sglang_radeon8060s.sh.

This is a prerequisite for resolving the Radeon 8060S to gpu_type 'radeon8060s': workload_envs pins {framework}{gpu_type}.sh with no existence check, so the board has to be resolvable to a script the installed Magpie actually carries. Split out from that change so the pin can be reviewed and validated on its own.

Changes:

• The bump carries 26 Magpie commits, not just the gfx1151 one, and they are not confined to new files. All six existing runner scripts change (vllm/sglang/atom for mi300x and mi355x) plus magpie_bench_remote_compat.sh (+203/-4). In vllm_mi300x.sh the eval invocation changes shape: run_eval --concurrent-requests $CONC + append_lm_eval_summary becomes magpie_run_eval_persisted, with concurrency moved to EVAL_CONCURRENT_REQUESTS. Sourcing of magpie_bench_remote_compat.sh also goes from [[ -f ]] && source to unconditional, so a missing file now fails rather than degrading quietly.
• Other commits in range with reach beyond gfx1151: default vllm version to v0.23.0 (bugs #73), persistent benchmark server reuse (Session breakdown #93), IntelliKit pins to v0.1.1 ([Marathon Mode] Support sandbox mount whitelist for checkpoint-based optimization continuation #87), eval concurrency argument compatibility (Inference-optimization skill skips moe kernels, which are tagged as vendor kernels. #89), and three TraceLens changes (Testing: auto label workflow #71, feat(skill): require GEAK model_config setup in inference-optimization (IR-7) #72, plus auto-cloning TraceLens main when the path is unset). Existing MI baselines should be re-validated against this pin before it is relied on for comparisons.
• d4de63d rather than Magpie main: it is the commit that introduces the gfx1151 runners and nothing after it is needed. It also sits immediately after c695962a ("Revert 'Add gfx11 (RDNA3/RDNA3.5) benchmark runner support' (test: verify Qwen LLM auto-labeling #94)"), so it is the attempt that stuck rather than the one that was rolled back.
• The old pin e6833b8 is not an ancestor of the new one. It and 61e6c5e6 ("Bump Magpie version to 0.2.0 (marathon harness #67)") share parent df36e76d and tree ddf13aa4, i.e. identical content -- the old pin was the pre-merge branch commit and the new pin descends from its squashed twin, so the pin moves onto main proper and nothing is dropped.
• The SHA is duplicated in three places -- install.sh's MAGPIE_REF default, preflight.py's inline fallback, and the test that asserts the two agree -- so all three move together. That test exists precisely to catch bumping one and forgetting another.
• MAGPIE_V020_COMMIT renamed to MAGPIE_PINNED_COMMIT and the test renamed from test_default_magpie_pin_is_v020_and_consistent to test_default_magpie_pin_is_consistent: neither refers to the v0.2.0 tag any more, and a name that says otherwise invites the next bump to leave it stale.

Verified: d4de63d's scripts/benchmark/ contains both vllm_radeon8060s.sh and sglang_radeon8060s.sh (checked against the Magpie repo, not assumed), and test_install_magpie_idempotent passes (5 tests).

• Description: what and why
• Linked issue(s): close/fix refs
• Tests: added/updated? commands run?
• Breaking changes: yes/no (details if yes)
• PR addresses single concern: yes/no (details if no):
• Root cause is upstream (Magpie/TraceLens/GEAK/IntelliKit/AgentKernelArena), ticket filed:

[mgehre-amd]

Superseded: main now pins Magpie at 6a1ee26f (via #1922, "Use Magpie's native AgentX contract for optimization"), which is a strict descendant of d4de63d — 21 commits ahead, 0 behind — and already ships vllm_radeon8060s.sh and sglang_radeon8060s.sh. Re-proposing d4de63d would now be a downgrade, so this PR has nothing left to do. The identity change in #1483 is unblocked by the pin main already carries.