Smoke-test the libFuzzer harness on pull requests

[matthargett]

What

Add a pull_request-triggered smoke test for the existing libFuzzer harness in tests/fuzz/wasm-mutator-fuzz/.

The full harness already runs continuously on OSS-Fuzz (google/oss-fuzz/projects/wamr), but nothing in-tree builds or exercises it on a pull request. So a change that breaks the harness build, or reintroduces a previously fixed loader/validator crash, is only caught out-of-band — an OSS-Fuzz report hours to days after merge. This moves that class of memory-safety regression to a check before review.

How

For each of fast-interp (default) and classic-interp, the job:

1. Installs the same toolchain OSS-Fuzz uses for this harness — LLVM 18.1.8 and wasm-tools 1.243.0.
2. Generates the wasm-smith seed corpus via the existing smith_wasm.sh.
3. Builds the wasm_mutator_fuzz target (ASan + UBSan + libFuzzer, from the harness's own sanitizer_flags.cmake).
4. Replays the committed tests/malformed/fuzz/*.wasm regression corpus (deterministic), then runs a short seeded bounded fuzz. Any crash / sanitizer error fails the job.

Fork / upstream safety

The job needs no secrets and no write permissions (permissions: contents: read); it builds and runs only, so it behaves identically for pull requests opened within a repository and from forks.

Notes

• Scoped to the two interpreter targets (the interpreter-only, most-exercised loader path); the llvm-jit / aot-compiler targets OSS-Fuzz also builds could be added.
• paths: limits the job to code / build / fuzz changes. If this is later made a required check, drop the filter or pair it with an always-pass companion job to avoid the required-check-plus-path-filter deadlock.
• libtinfo5 (needed by the prebuilt LLVM's clang at runtime) is resolved at the runner's actual ncurses version with a pool-scrape fallback, rather than a hard-coded security-pocket .deb URL, so the install survives ncurses point-release bumps. The same hard-coded-URL pattern in .github/scripts/codeql_buildscript.sh is currently broken; fixed separately in Fix the currently-failing CodeQL workflow and run it on pull requests #4980.

Verification

Verified end-to-end on a pull request in a fork: both matrix legs build and run green in ~3.5 min each.

[lum1n0us]

I am inclined to hold this PR for two reasons: first, I have concerns regarding the GitHub Actions budget; and second, I believe we need a broader and more clearly defined feature matrix — one that includes, at minimum, Wasm 1.0 support, as well as the Tier-A running mode, which is currently under discussion

[matthargett]

I am inclined to hold this PR for two reasons: first, I have concerns regarding the GitHub Actions budget; and second, I believe we need a broader and more clearly defined feature matrix — one that includes, at minimum, Wasm 1.0 support, as well as the Tier-A running mode, which is currently under discussion

THe intent isn't to run the full fuzzer, but just replay the corpus that previously found bugs as a smoke test. I did have github actions budget in mind :)

I agree it's not critical, since the nightly run via openfuzz etc will catch things pretty quickly. let me know if you want me to expand this one to more functional areas, or back up and start with a different slice of the semi-automated feedback loop on PRs! :D