[wasm-exceptions] Probable memory corruption when doing try...catch...rethrow

We were using emsdk `3.1.35` when we encountered a weird memory access out of bound error on latest Safari (Safari 18). The same error wasn't reproducible on chrome. Initially we thought there could be an error in latest Safari. The code in our codebase at which we were getting the error was like below:

```cpp
#include
#include

int main() {
try {
throw std::runtime_error("Error inside main");
} catch (const std::runtime_error &e) {
std::cout << "Caught exception: " << e.what() << " and rethrowing"
<< std::endl;
throw;
}
return 0;
}
```

We tried building above sample code (with emsdk 3.1.35) with address sanitizer using command:
```sh
em++ -fwasm-exceptions -fsanitize=address a.cpp -o a.html
```
With address sanitizer builld, this code started giving below error on all browsers (including Chrome):
```
a.js:10 Uncaught RuntimeError: unreachable
at a.wasm:0x227e
at a.wasm:0x61bf
at a.js:612:20
at callMain (a.js:4785:13)
at doRun (a.js:4815:21)
at a.js:4824:4
```

We definitely knew there was something wrong in the 3.1.35 emsdk version. We upgraded the emsdk version to 3.1.56 and this error with the address sanitizer in the sample code was gone. Upon bisecting we could find that there was some LLVM update that fixed it.

But when we used the same emscripten version with our actual codebase we were still getting the same error on Safari 18. As of now, we also tried with emscripten `tot` but the error in our codebase persists. We tried building our codebase with address sanitizer so that it may get reproduced on other browsers as well but no luck. Don't know if something has changed in the address sanitizer in newer emsdk versions which has caused it to not give the same error or any actual fix has been done.

Additionally, if we build our codebase with js exceptions (`-sDISABLE_EXCEPTION_CATCHING=0`) we do not get any memory access out of bound (memory corruption) issue. This shows that, there is definitely something wrong with wasm-exceptions implementation and above described `try...catch...rethrow` flow.

Its unfortunate that we do not have a sample code that is reproducing the issue on latest emscripten. But we have some information that can help investigation get started.