fix: clear exec_env_tls when destroying exec_env

[teamchong]

Problem

When wasm_exec_env_destroy() is called, exec_env_tls (thread-local storage used by signal handlers for hardware bounds checking) may still point to the exec_env being destroyed. On subsequent WASM executions in the same thread, if a signal occurs (e.g., SIGSEGV for bounds checking), the signal handler accesses freed memory and crashes.

Solution

Clear exec_env_tls if it points to the exec_env being destroyed. This is a simple defensive check that prevents dangling pointer issues.

#ifdef OS_ENABLE_HW_BOUND_CHECK
    WASMExecEnv *current_tls = wasm_runtime_get_exec_env_tls();
    if (current_tls == exec_env) {
        wasm_runtime_set_exec_env_tls(NULL);
    }
#endif

Use Case

Daemon-style execution patterns (like Cloudflare Workers) where the same thread runs multiple WASM modules sequentially without forking. Each module creates its own exec_env, runs, then destroys it. Without this fix, the TLS can point to a destroyed exec_env, causing crashes on subsequent runs.

Testing

• Tested in production daemon-style execution with 100+ consecutive AOT runs without crashes
• No regression in existing tests expected (the fix only adds a NULL check)

Related

• Is it safe to have two `exec_env`s at the same time? #2381