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

從 Lib/multiprocessing/connection.py 中 _exhaustive_wait() 的 Windows 分支開始，重點檢查用於篩選就緒控制代碼的清單推導式。確認運算子運算式與 issue 中所示的預期篩選方式一致；完成的標準是排除已發出訊號的控制代碼並保留未發出訊號的控制代碼，而 gh-156071 表示相關工作已經在進行中。