[summeriver13]

The interrupt channel is write-only. The client only calls sendall() on it
(Lib/pdb.py:3517), and the target only reads. Half-closing the target's write side
therefore sent a FIN that no one consumed, and Windows keeps a half-closed connection
in FIN_WAIT_2 for 120 seconds and then resets it. An idle debugging session silently
lost its interrupt channel.

Dropping the call leaves the connection in ESTABLISHED until one end closes it.
Nothing else changes: the listener still polls with a 0.25 s timeout, so it can exit
when the interpreter shuts down.

The half-close came in with the first version of the listener (5993e06, gh-132975).
Its author confirmed that it was only meant to document the one-way direction:
#160683 (comment)

The new test starts _PdbServer._start_signal_listener() in a subprocess and asserts
that the accepted socket never sees EOF. With the half-close put back, it fails in
147 ms, so it does not depend on the 120 s timer; with this change it passes.

I ran python.exe -m test test_remote_pdb test_pdb on Windows 11 (26100) with a
Release/MSVC build: 289 tests run, 17 skipped, all pass. This affects 3.14 and 3.15
as well; both branches have the same listener.

Fixes #160683

• Issue: Windows: remote pdb loses its interrupt connection after about 120 seconds #160683

[summeriver13]

All checks are green, including the Windows builds.

@gaogaotiantian, could you review this? It only touches Lib/pdb.py: the interrupt listener stops half-closing the socket. A half-closed connection waits in FIN_WAIT_2, and Windows resets it after 120 seconds, which drops the interrupt channel of an idle remote session (gh-160683). The author of that line confirmed that it only documented the one-way direction: #160683 (comment)

The new test starts the listener in a subprocess and asserts that the accepted socket never sees EOF. It fails in 147 ms without the change.