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

Comece em Lib/multiprocessing/connection.py, no branch do Windows de _exhaustive_wait(), concentrando-se na compreensão de lista que filtra os handles prontos. Confirme se a expressão do operador corresponde à filtragem pretendida mostrada na issue; considera-se concluído quando os handles sinalizados são excluídos e os não sinalizados permanecem, com gh-156071 indicando que o trabalho já está em andamento.