Fire the close event on MessagePort - #32565

Adding a `close` listener to an already-closed port pins its JS wrapper for the lifetime of the context. `close()` with no listener leaves `m_closeEventDispatched=false`, then `addEventListener('close', ...)` (which has no `m_isDetached` guard) sets `m_hasCloseEventListener=true`; this branch now returns `true` forever because it runs before the `m_isDetached` check and nothing will ever clear the flag. Either set `m_closeEventDispatched=true` in `close()`'s `!scheduledClose` fallthrough (and ga

Adding only a `close` listener (no `message` listener, no explicit `start()`) leaves the port un-`Attached` on the pipe, so the new peer-wake block in `MessagePortPipe::close()` skips it and the peer's `close` event never fires — diverging from Node, where `port2.on('close', cb)` alone fires when `port1.close()` is called. Worse, the new `hasPendingActivity()` branch then returns `true` forever (`m_hasCloseEventListener && !isOtherSideOpen`), pinning the wrapper for the lifetime of the context —