Skip backtrace capture in trap handlers to eliminate lock contention

[ndr-ds]

Description

Eliminate all Backtrace::new_unresolved() calls in trap handling paths.

Backtrace::new_unresolved() calls _Unwind_Backtrace, which invokes
_Unwind_Find_FDE for each stack frame. This takes a process-wide mutex (either
object_mutex in libgcc or dl_iterate_phdr's internal lock in glibc). Under high
concurrency — hundreds of async tasks executing WASM contracts simultaneously — this
causes severe lock contention. In production we observed 67% of CPU time spent in
native_queued_spin_lock_slowpath (the kernel futex spinlock beneath the contended
mutex), pinning workers at 100% CPU utilization.

Changes

• lib/vm/src/trap/traphandlers.rs: Always use Backtrace::from(vec![]) in the
  signal-based trap handler instead of conditionally calling Backtrace::new_unresolved()
  (previously only skipped for stack overflow traps).
• lib/vm/src/trap/trap.rs: Trap::lib() and Trap::oom() constructors use empty
  backtraces.
• lib/compiler/src/engine/trap/stack.rs: Trap::User variant returns an empty
  WASM trace instead of capturing a new backtrace during Trap → RuntimeError
  conversion.

Trade-off

The WASM-level stack trace (FrameInfo frames shown in RuntimeError Display) is lost
— error messages will show RuntimeError: unreachable without the at function_name (module[N]:0xOFFSET) lines. The trap code and the original panic/error message are
fully preserved.

[Twey]

I'm confused — does that mean we have some code path that is trapping in a loop? How could we be spending 67% of CPU time in any error-handling path?

(Nit: we execute Wasm in threads, not tasks — Wasm execution is currently fully synchronous, so blocks the thread)

[ndr-ds]

Yes, I was confused by that too, but the CPU profile seemed to point to the CPU usage coming from the WASM panics. That turned out to be wrong 😅 Even though it could, it wasn't in this particular situation.
The actual problem was something else, which is also already fixed. The WASM backtraces were not providing much useful information anyways, so it's still a positive thing we removed it I guess 🤷🏻‍♂️