docs: evaluate arXiv 2604.13693 (WarpL) for meld CI use

[avrabe]

Summary

Evaluation memo on whether the WarpL technique from
arXiv:2604.13693 (Zeng, Jiang,
Zhao, Zhou, ICSE '26) fits as a meld CI signal on fused / optimised
output.

TL;DR (from the memo)

The brief framed WarpL as a perf-regression detector with five
captured "baseline signatures." In reality WarpL is a post-hoc
root-cause localiser for already-known slow programs: it needs a
second Wasm runtime as a differential oracle, costs ~14 h per
case (3 h mutation+selection+isolation + 11 h `wasm-reduce`), has
no signature representation, and was demonstrated only on stock
runtime issue-tracker bugs — never on component-model / fused
output.

Recommend: defer. Not implement as PR-CI, not as nightly.
Bookmark for the narrow case where a meld-fused module runs slowly
on a specific downstream runtime and we need to attribute blame
between meld and the JIT.

What the memo also covers

• A what-the-brief-described vs. what-the-paper-does comparison table
• The actual WarpL pipeline (4 steps)
• Three cheaper detectors that fit the underlying perf-regression
  ask (criterion benches already shipped; per-fixture `wasmtime run`
  exec time; `wasm-opt -O3` size deltas)
• The 5 fixtures we'd reach for if such a detector lands later
  (`numbers`, `lists`, `flavorful`, `calculator`,
  `yolo_inference_release`)

Scope

• meld-only. The original brief paired this with `pulseengine/loom`;
  the loom half was descoped at user direction.

Test plan

• Memo reads cleanly in GitHub markdown rendering
• Links to the arXiv abstract and the WarpL GitHub repo resolve
• No code or workflow changes — pure docs