Debugging test via VSCode code lens built against sherpa-rs throws dynamic linker error (not present in "run test" code lens or running via cargo test)

rust-analyzer version: rust-analyzer version: 0.3.2273-standalone [/home/vlovich/.vscode-server/extensions/rust-lang.rust-analyzer-0.3.2273-linux-x64/server/rust-analyzer]

rustc version: rustc 1.84.0 (9fc6b4312 2025-01-07)

editor or extension: VSCode 0.3.2273

relevant settings: N/A

repository link (if public, optional): https://github.com/thewh1teagle/sherpa-rs

code snippet to reproduce:

#[cfg(test)]
#[test]
fn test() {
    let _config = sherpa_rs::whisper::WhisperConfig::default();
}

If I run the test via "Run Test" code lens or command line "cargo test" it works fine. If I try to debug the test via code lens, the executable fails to launch with error while loading shared libraries: libsherpa-onnx-c-api.so: cannot open shared object file: No such file or directory. The build.rs from sherpa-rs-sys is set up correctly (at least those paths have the .so on them). If I manually add a LD_LIBRARY_PATH to the rust-analyzer.runnables.extraEnv variable pointing to a folder containing the so it works, but it's annoying & non-ideal (since I don't actually know which profile the analyzer is using to launch - don't think there's a variable expansion that works for that which would at least mitigate the short-term pain of that).

This is documented as a known issue:
https://github.com/thewh1teagle/sherpa-rs/blob/main/BUILDING.md#shared-library-not-found-while-its-in-the-same-directly-of-executable

Start with the sherpa-rs-sys build.rs and the linked BUILDING.md note, then compare the environment used by the Run Test code lens, cargo test, and the debug code lens. Reproduce the test with the sherpa-rs example and inspect rust-analyzer.runnables.extraEnv behavior. Done means the debug launch finds libsherpa-onnx-c-api.so without a manual LD_LIBRARY_PATH.