chore: build ordinary CI against llama.cpp v0.5.0

[leehack]

Summary

Move the ordinary CI/development pin in llama_cpp.version from v0.2.0 to v0.5.0, and update the one test that asserts its value (release_contract_test.py).

The pinned CI lane then builds the bridge and runs its smokes against llama.cpp v0.5.0. That happens before llamadart-native publishes its v0.5.0 release (still blocked on leehack/llamadart-native#92 and leehack/llamadart-native#93). Once native publishes, the orchestrator builds a publishable candidate from native's upstream tag. If the bridge breaks on v0.5.0, it's better to find out here: a failed candidate is never retried automatically.

What does not change

• Release candidates still take upstream_tag from the native release; bridge_candidate.yml never reads llama_cpp.version. Published assets are unaffected.
• The exact v0.4.0 compatibility lane stays as it is.

After merge

llama_cpp.version is a governed path, so the next orchestrator scan dispatches one new candidate for native v0.4.1-1, probably claiming v0.1.50. It builds from native's v0.4.1, so its bytes should match v0.1.49. In that case the pipeline ends as satisfied_by_identical_release, with no qualification or publication, and the tag is freed.

Review notes (independent review, nothing blocking)

• No other file restates the pin value. README, AGENTS and CONTRIBUTING only name the file, and verify_ci_reliability.py only checks the tag's format.
• The wasm64 WASMFS patches edit Emscripten's output, so they depend on Emscripten, not llama.cpp.
• Every llama.cpp layout dependency in CMakeLists.txt still holds in v0.5.0: the mtmd-audio.cpp thread marker, the mtmd sources, vendor::hash, and tools/mtmd/CMakeLists.txt, which is unchanged since v0.4.0.
• The v0.5.0 public header changes are additive and not used by the bridge.
• mtmd_helper_init_opt_default exists in v0.5.0, so the pinned lane now builds the options path. The legacy no-options fallback is still covered by mtmd_compat_contract_test.py against stubs.
• Only CI can confirm that v0.5.0's new -Xclang -fno-pch-timestamp flag for Clang-ID compilers works with emcc.

Local verification

• npm run check:js
• the CONTRIBUTING lightweight contract list, including python3 scripts/verify_ci_reliability.py </dev/null
• python3 -m unittest discover -s scripts -p '*_test.py' </dev/null: 416 tests, OK

The real v0.5.0 build and the browser smokes are this PR's CI. I couldn't run them locally because the local emcc is 6.0.10-git and the pin is 6.0.8.