vfs: re-register epoll waiter after restore to fix missed notifications

[pawannn]

Fixes #13920.

Problem

After checkpoint/restore, an epoll instance that was registered before the checkpoint may stop receiving events.

For example, on a restored TCP listening socket:

• poll(2) reports the socket as readable.
• A newly created epoll instance also reports it as ready.
• But the epoll instance that existed before the checkpoint never receives the event.

Impact

Applications that rely on epoll (such as those using Tokio or mio) can stop accepting new connections after restore. Connections continue to arrive, but epoll_wait() never wakes up, so accept(2) is never called.

Root cause

An epoll interest registers a waiter with the file's waiter.Queue so it can receive readiness notifications.

After restore, that waiter is no longer registered with the queue. As a result, future notifications never reach the restored epoll interest, even though the file itself becomes ready.

What this change does

This change updates epollInterest.afterLoad to re-register the waiter with the file's waiter.Queue during restore.

This restores event delivery while preserving the existing behavior, including skipping deleted interests (mask == 0).

Tests

Added pkg/sentry/vfs/epoll_test.go with three tests:

• TestEpollInterestAfterLoadReRegistersWaiter verifies that notifications are delivered again after restore. It fails without this change and passes with it.
• TestEpollInterestAfterLoadPreservesReadyState verifies that the existing "mark ready after load" behavior is preserved.
• TestEpollInterestAfterLoadSkipsDeleted verifies that deleted interests are still skipped.

Verification

State	Result
With the fix	//pkg/sentry/vfs:vfs_test PASSED
Fix reverted	TestEpollInterestAfterLoadReRegistersWaiter FAIL: got 0 events, want 1
Fix restored	//pkg/sentry/vfs:vfs_test PASSED

Result

After restore, epoll continues receiving readiness notifications as expected, allowing applications to resume accepting new connections normally.