multiprocessing.connection._exhaustive_wait: `&` used instead of `and` when filtering ready handles on Windows

Bug report

Bug description:

In Lib/multiprocessing/connection.py, the Windows branch of _exhaustive_wait() that handles more than 60 handles (added in gh-89240 / GH-107873) filters the already signalled handles out of the list with

            if res:
                L = [h for i, h in enumerate(L) if i > res[0] & i not in res]

& binds tighter than the comparison operators, so this parses as the chained comparison i > (res[0] & i) not in res, i.e. i > (res[0] & i) and ((res[0] & i) not in res), which is not the intended i > res[0] and i not in res. For example with res = [2, 5] and eight handles it keeps indexes 1, 4, 5 instead of 3, 4, 6, 7, so signalled handles can stay in L (and be waited on and reported again) while unsignalled ones are dropped.

>>> res = [2, 5]; L = list("abcdefgh")
>>> [h for i, h in enumerate(L) if i > res[0] & i not in res]
['b', 'e', 'f']
>>> [h for i, h in enumerate(L) if i > res[0] and i not in res]
['d', 'e', 'g', 'h']

pylint reports the line as bad-chained-comparison ("suspicious 2-part chained comparison using semantically incompatible operators ('>' and 'not in')"), which is how I found it. The fix is to use and.

CPython versions tested on:

CPython main branch, 3.14

Operating systems tested on:

Windows (code path), found on macOS by static analysis

• gh-156071

Bắt đầu trong Lib/multiprocessing/connection.py tại nhánh Windows của _exhaustive_wait(), tập trung vào list comprehension lọc các handle sẵn sàng. Xác nhận rằng biểu thức toán tử khớp với cách lọc dự kiến được nêu trong issue; hoàn thành có nghĩa là các handle đã được báo hiệu bị loại trừ và các handle chưa được báo hiệu vẫn còn, trong đó gh-156071 cho biết công việc đã được tiến hành.