test(core): cover VM disposal after guest fetch

[RitikaxG]

• Add a fresh-sidecar regression for a guest fetch() whose response body is fully consumed, then require VM disposal before the 5-second shutdown deadline.
• Run the regression in the required Core PR test lane. It failed on the pre-fix base at 5,047 ms with one VM timer task retained and passes on current main after upstream commit a6c668c made timer-wheel initialization process-owned.

Related: #1989

This covers the completed-response disposal path. The unread-response evaluation delay needs separate investigation.

[the-company-company]

🔴 1 high-severity finding

_{Reviewed commit f26c94d.}

[the-company-company]

🔴 High · Python can still bind the global timer wheel to one VM

PythonExecutionEngine::new(vm_runtime.clone()) constructs its embedded JavascriptExecutionEngine with this VM-scoped context. Python executions are ultimately started through that engine, whose LocalBridgeState passes the engine context to TimerWheel::get; if Python is the first runtime to schedule a JS/bridge timer, the process-global wheel is therefore still spawned under this VM's admission scope and dies when the VM is disposed, leaving later VMs with the same dead singleton. WasmExecutionEngine::new(vm_runtime) on the next line has the same path. Give both wrapper engines the process runtime for their embedded JavaScript host while retaining the VM runtime for guest execution, and cover first-use through Python/Wasm before disposing the VM.

[the-company-company]

✅ No issues found

_{Reviewed commit e5aa7f3.}