I copied half of that file, commented out include for select.h, removed the check and now it works

=== Test 2: pselect() with FD >= FD_SETSIZE (DANGEROUS!) ===
This test intentionally demonstrates undefined behavior
Attempting to add FD 1024 to fd_set (FD_SETSIZE=1024)...
WARNING: This will cause undefined behavior!
Before FD_SET: fd_set memory looks normal
fd_set bytes before: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Calling FD_SET(1024, &dangerous_set)...
fd_set bytes after:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Memory corruption may have occurred!
Attempting pselect() with corrupted fd_set...
pselect() unexpectedly succeeded with 0 ready FDs

I don't know if "works" means more than "it returned 0" but...

Setting the _DARWIN_UNLIMITED_SELECT macro will select the extension variants of select() and pselect(), which uses the $DARWIN_EXTSN suffix. The extended versions do not fail if the first argument is greater than FD_SETSIZE. This was the original BSD behavior.

claims on how this works

Apple's libc has a pretty wild feature (guarded by _DARWIN_UNLIMITED_SELECT, on by default) which allows fds above FD_SETSIZE. It works by checking the address of the fd_set: if it's within the current thread's stack, then the call will fail, under the assumption that it's a stack-allocated fd_set.
But if the address is NOT within the current thread's stack, select() assumes you know what you're doing and will allow the call, trusting you have allocated sufficient memory for the high fds in the fd_set.

so there may be some condition to fulfill to make it work.

which I think is not satisfied for qemu main loop fds?