[DO NOT MERGE] check if xeus-cpp latest commit is causing Emscripten ci failures

[mcbarton]

Description

Please include a summary of changes, motivation and context for this PR.

Fixes # (issue)

Type of change

Please tick all options which are relevant.

• Bug fix
• New feature
• Requires documentation updates

Testing

Please describe the test(s) that you added and ran to verify your changes.

Checklist

• I have read the contribution guide recently

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.04%. Comparing base (2df83a9) to head (c574080).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #749   +/-   ##
=======================================
  Coverage   79.04%   79.04%           
=======================================
  Files           9        9           
  Lines        3879     3879           
=======================================
  Hits         3066     3066           
  Misses        813      813           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[anutosh491]

Hi,

Let's do some more experimentation and try to pin-point if xeus-cpp's 402 is the real error.

As we're not merging this and we can play around with the forks. @mcbarton let's use your fork here and maybe a trial branch here.

Approach 1

1. Let's comment out every other tests (line 69 - line 1096) apart from the concering test. We just need the StreamRedirectRAII class at the top and our test.
2. Then let's see if the CI still says the same. if we run just 1 test and that 1 test fails, that tells us that it might not be a node or a memory out of bound error of some sorts. Hopefully we are using node 22

Approach 2

1. I think for xeus-cpp's test we are just using node right and not running the tests in the browser. node is just 1 runtime for wasm ..... we already have the setup to run the tests in the browser in cppinterop's CI, let's extend it (maybe just in this PR) and try to run the tests in the browser too.
2. if it fails at both places, that again we have some concrete proof that more than 1 wasm runtimes fails in the CI.