child_process: emit close after parent disconnect

[rasadregmi]

When the parent calls subprocess.disconnect() before the IPC channel reaches EOF, the close event is never emitted after the child exits. disconnect, exit, and stdio close all fire, so code waiting on close hangs even though the child process and its pipes are gone.

The IPC channel slot is normally accounted for by maybeClose(), called from the channel's EOF handler, but that path is never reached when the parent closes the channel itself: _disconnect()'s finish() closed the channel and emitted 'disconnect' without calling maybeClose(), so _closesGot never reached _closesNeeded and the close event was lost.

This change counts the channel closure in finish() after emitting 'disconnect'. The EOF handler now performs that accounting only when _disconnect() was deferred by a pending handle queue (the case where the child exits before the queue drains), so each channel closure is still counted exactly once and the EOF path plus exit-before-close ordering are preserved.

Regression test test/parallel/test-child-process-disconnect-close.js asserts that close is emitted exactly once with (0, null) after a parent-initiated disconnect(); it fails on current main and passes with this change. The full test/parallel/test-child-process-*.js suite passes locally.

Fixes: #65646

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

[rasadregmi]

Closing in favor of #65665 which addresses this more thoroughly, including handle queue cleanup.