WASM: Cv2.DrawMatches crashes the Mono interpreter (ves_pinvoke_method / get_build_args_from_sig_info)

Summary

On a Blazor WebAssembly build where OpenCvSharp.dll is excluded from AOT and runs under the Mono interpreter (a workaround for a separate mono-aot-cross crash, see shimat/opencvsharp_blazor_sample#8), calling Cv2.DrawMatches(...) crashes the whole WASM runtime instead of throwing a catchable .NET exception.

Repro context

In shimat/opencvsharp_blazor_sample's Feature Matching sample, after successfully running AKAZE.DetectAndCompute and BFMatcher.Match on two images, calling:

Cv2.DrawMatches(img1, keypoints1, img2, keypoints2, matches, outImg);

hangs/crashes the page. Browser console shows:

[MONO] interp.c:1502
...get_build_args_from_sig_info...
...ves_pinvoke_method...
program exited (with status: 1)

Notes / narrowing

• This is not the OpenCL/UMat issue tracked in #2037 — DrawMatches doesn't touch UMat internally.
• Cv2.DrawKeypoints (5 parameters: InputArray, IEnumerable<KeyPoint>, InputOutputArray, Scalar?, DrawMatchesFlags) works fine under the same interpreted-execution conditions.
• Cv2.DrawMatches has a much larger P/Invoke signature (Mat, IEnumerable<KeyPoint> x2, Mat, IEnumerable<DMatch>, Mat, Scalar? x2, IEnumerable<byte>?, DrawMatchesFlags — 10 parameters total), which suggests Mono's interpreter has a limitation marshalling P/Invoke signatures past some complexity/parameter-count threshold, rather than anything specific to this one method.
• Current workaround in the sample: avoid Cv2.DrawMatches entirely and draw the side-by-side comparison + correspondence lines manually with Cv2.Line/Cv2.Circle/Mat ROI indexing instead.

Ask

This may ultimately be a Mono/wasm interpreter limitation (arguably better filed against dotnet/runtime) rather than something fixable in OpenCvSharp itself, but filing here first since the immediate practical impact is "OpenCvSharp API X can't be called on wasm-under-interpreter." Any guidance on which complex-signature P/Invoke declarations are known-safe on wasm (or whether this should move to dotnet/runtime) would help other consumers running OpenCvSharp under the same AOT-exclusion workaround.

Reproduce the crash in the Feature Matching sample after AKAZE.DetectAndCompute and BFMatcher.Match, then compare Cv2.DrawMatches with the working Cv2.DrawKeypoints call under interpreted WASM execution. Inspect the OpenCvSharp P/Invoke declaration and the Mono interpreter failure details to determine whether the issue is actionable here or belongs in dotnet/runtime. Done means establishing the owning component and documenting a confirmed fix, limitation, or routing decision.