fix: fix handle paths in FSA entries iterator

[quickgiant]

Hi! Thanks for working on this library. The File System Access API adapter has been helpful for testing a project I'm working on.

I noticed in one of my test suites that when using file handles retrieved from the NodeFileSystemDirectoryHandle.entries() async iterator, the getFile() method would throw an ENOENT error, with the message suggesting it was trying to read the file using just the name instead of the full path.

This appears to be a typo in the implementation, so I changed it to pass the full path when constructing file handles and added an assertion to the relevant test case that checks that the file entries can be read.

[G-Rath]

Thanks! Would you mind adding an equivalent assertion to the directory example too?

[quickgiant]

Yeah I can do that. Is it okay if it checks the __path property? I was trying to avoid writing implementation-specific assertions, but I'm not sure there's another good way to check the path for directory entries.

Edit: Added another test case checking __path and discovered that separators were being added twice due to there already being a trailing slash in the base path. Fixed that bug as well and will update the PR title.

[G-Rath]

I'm not too familiar with this side of the library so couldn't say off the top of my head, but what I was meaning was just the same instanceof assertion you've added in this PR (I'm assuming there's an equivalent Directory type class like there is File, but if that's not the case we can skip this)

[quickgiant]

Yeah there's no equivalent to getFile(). The FileSystemDirectoryHandle class only includes the async iterator methods, getters for child handles, and a method to remove (delete) entries.

[G-Rath]

This has gotten released as v4.8.1 on npm but it looks like the GitHub credentials for semantic release are broken so it hasn't added the release or posted it's usual comment here.

@streamich can you update the GitHub token for ci? seems this happened for the last release too