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 表明相关工作已经在进行中。