Don't fail profile processing when a marker's stack field is not a backtrace

[fqueze]

The marker payload stack key normally holds a captured backtrace (a mini thread with a samples table), which we convert into a cause. But the key isn't reserved: some markers store an unrelated value there, e.g. Log markers emitted by the test harness put a textual JS stack trace string in it. Processing such a marker threw (accessing .samples.data on a string), making the whole profile fail to load.

Check that the stack value actually has a samples table before treating it as a backtrace. A non-backtrace stack is now left untouched on the payload, to be displayed (or ignored) by the marker schema like any other field.

Example profile that fails to load without this fix: https://share.firefox.dev/49tsCeI

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.77%. Comparing base (c2e302e) to head (52f65d8).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6069   +/-   ##
=======================================
  Coverage   83.77%   83.77%           
=======================================
  Files         329      329           
  Lines       34557    34559    +2     
  Branches     9668     9574   -94     
=======================================
+ Hits        28950    28952    +2     
  Misses       5178     5178           
  Partials      429      429           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.