Fix false positive for os.sendfile via asyncio sock_sendfile path

[agners]

Summary

Extends the os.sendfile whitelist to also allow the selector event loop's socket-level path (asyncio/unix_events.py:_sock_sendfile_native_impl). This is the path aiohttp's FileResponse ends up on when serving static files, so any aiohttp app using blockbuster currently hits a false positive BlockingError.

The whitelisted call site runs os.sendfile on a non-blocking socket and explicitly handles BlockingIOError/InterruptedError by registering a writer on the fd — i.e. the syscall returns EAGAIN instead of blocking, just like the already-whitelisted asyncio/base_events.py:sendfile path.

The two whitelist entries cover the two stack shapes that reach os.sendfile:

• when the first os.sendfile call sends everything in one go, the call frame chain includes base_events.py:sendfile directly (covered by the existing entry)
• when the socket fills before the file does, asyncio sets up an add_writer callback and re-enters _sock_sendfile_native_impl from the event loop's callback dispatch — the stack no longer goes through base_events.py:sendfile, so we need the new entry

Fixes #57

Test plan

• Existing test_os_sendfile still passes (uv run pytest -k sendfile)
• Reproduced the false positive locally on Python 3.14.5 + aiohttp 3.13.5 + blockbuster 1.5.26 using a slow client + small SO_RCVBUF to force the EAGAIN/add_writer path
• With this patch applied, the same reproducer streams the full file cleanly with no BlockingError in the server logs