ci(release): highs-sys WASI cross-compile fails — root-cause + restore test-evidence as required

[avrabe]

Context

The v0.10.0 release workflow (run 25966236046) succeeded on all cross-platform binary builds but failed on `build-test-evidence`. The failure traces to spar's transitive `highs-sys` dependency:

```
CMake Error at highs/CMakeLists.txt:364 (target_link_libraries):
Target "highs" links to:
Threads::Threads
but the target was not found.
```

This is the WASI sysroot lacking the `Threads::Threads` CMake target — the wasi-sdk integration done in #274 doesn't supply it.

Immediate workaround (this PR)

In the workflow patch landing alongside this issue: `build-test-evidence` is now `continue-on-error: true` and removed from `create-release`'s `needs`. The release now publishes binaries even when test-evidence fails.

What needs to happen here

1. Reproduce the failure locally with wasi-sdk 25.0 + `cargo build -p spar --target wasm32-wasip2`.
2. Investigate whether `highs-sys` needs a feature flag to skip threading on WASI, or whether the wasi-sysroot needs a stub `FindThreads.cmake`.
3. Upstream the fix to `highs-sys` or `spar` (vendor a build-script patch in `spar` first if highs-sys is unresponsive).
4. Once green, revert the `continue-on-error` + re-add `build-test-evidence` to `create-release` needs.

History

• ci(release): make build-test-evidence non-blocking #272 made test-evidence non-blocking originally.
• ci(release): wire wasi-sdk into build-test-evidence #274 reverted that with the wasi-sdk integration, expecting it to work.
• v0.10.0 reproduced the failure, requiring manual release publication from workflow artifacts.

Refs: #272, #274, release run 25966236046, v0.10.0 manual republish 2026-05-16.

[avrabe]

Triage (issue-triage agent run 2026-05-16):

The body's "What needs to happen here" section lays out a sequential investigation path (reproduce → diagnose → upstream → revert) rather than a bulleted set of testable done-statements. For autonomous pickup under the oracle-gated workflow this needs an explicit ## Acceptance Criteria block. Sketch of the shape expected (matching #237 / #249 / #248):

## Acceptance Criteria
- [ ] `cargo build -p spar --target wasm32-wasip2` succeeds locally on wasi-sdk 25.0 with the chosen fix applied
- [ ] Root cause documented in this issue (highs-sys CMake threading vs. wasi-sysroot stub)
- [ ] Fix lands either as a `highs-sys` upstream release, a vendored build-script patch in `spar`, or a feature flag on `spar` that skips highs on WASI
- [ ] `.github/workflows/release.yml` has `build-test-evidence` re-added to `create-release`'s `needs` with `continue-on-error` removed
- [ ] One green release run end-to-end (binaries + test-evidence) recorded in the issue before close

Scope blockers for this agent:

1. The fix path explicitly involves highs-sys upstream and/or spar (vendor a build-script patch first if upstream is unresponsive). My GitHub MCP write surface is scoped to pulseengine/rivet only — I can't open PRs in pulseengine/spar or upstream highs-sys. Whichever side of the boundary the actual fix lives on, that part has to be hand-driven or done from a session scoped to the right repo.
2. The reproduction step requires a wasi-sdk 25.0 + wasm32-wasip2 cross-build environment, which isn't available in this sandbox.

What is in-scope here is only step 4 of the body — the workflow revert — and that's a no-op until the upstream fix exists. So even with explicit AC, the rivet-side PR can only be the last commit of the chain.

Suggestion: consider splitting this into two issues:

• pulseengine/rivet issue with AC = "revert continue-on-error once upstream fix tag is published" (one-line workflow change, agent-tractable once unblocked).
• pulseengine/spar (or upstream highs-sys) issue with AC = the actual CMake/threading fix.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-05-16.

---

Generated by Claude Code