fix: handle readdir offset != 0 by snapshotting the directory

[Yike-Ye]

Replaces #371 (closed).

Problem

sshfs uses mode-1 readdir — it ignores the offset and hands the whole listing to the filler with offset 0 — but also asserted offset == 0 in three places:

• sftp_readdir_async() (sshfs.c)
• sftp_readdir_sync() (sshfs.c)
• cache_readdir() (cache.c)

That assertion is an invalid assumption, and a long-standing one. Calling readdir with offset != 0 is legal, and the mismatch was already reported in #211 (2020, on FreeBSD via seekdir) — where @Nikratio confirmed the code "is buggy ... it certainly can be fixed" and suggested exactly this fix: "always retrieve the full list from the SFTP server and buffer it in memory." A mode-1 filesystem must still return the full listing when called with a non-zero offset, rather than assert or return nothing.

The bug only became acute on macOS with macFUSE 5.3.x. macFUSE is transitioning its backend from the kernel extension toward Apple's FSKit framework (as macOS deprecates third-party kexts), and as part of that transition 5.3.x reworked directory enumeration — 5.3.1 switched to the node identifier and generation as the authoritative handle instead of the inode number, and added a FUSE_LOOKUP on the entries returned by FUSE_READDIR. We can only speculate that this is why readdir is now called with offset != 0 so much more often (#338), but the fix does not depend on the cause. It is sshfs's own contract violation — the process aborts on the assert, and the earlier return 0 attempt (#371) empties the listing instead — and it is observed on macFUSE 5.3.x on both the FSKit and kernel-extension backends.

Fix

Remove the assert(offset == 0) in all three locations (and drop the now-unused #include <assert.h> from cache.c), and handle a non-zero offset correctly by buffering the whole directory, along the lines @Nikratio suggested:

• sshfs_readdir() keeps a snapshot of the current enumeration. An SFTP directory handle is single-pass — once read to SSH_FX_EOF it yields nothing — so on offset == 0 (a fresh listing or a rewinddir) it re-opens the handle if it has been exhausted and re-reads the whole directory from the server, rebuilding the snapshot. A continuation (offset != 0) is served from that snapshot, always filling with offset 0 so libfuse does the slicing.
• Because each fresh enumeration re-reads from the server, newly created files and updated attributes show up on the next listing rather than being masked by a stale snapshot. This was a real regression while the snapshot was retained across enumerations — @dmik observed newly created files not appearing under a VS Code workload — and is why the re-read happens on every offset == 0 rather than once per open handle.
• cache_readdir() ignores the offset entirely and, when the cache is stale, always requests a fresh, complete enumeration. (@dmik confirmed the vanishing itself was not caused by caching — it reproduced with the cache disabled — so this is for contract-correctness, not the primary fix.)

No platform #ifdef is involved: handling offset != 0 this way is correct on every platform, so the assertions are dropped unconditionally.

Testing

@dmik stress-tested this branch (VS Code on a large .git project, overnight idle with -o ServerAliveInterval=15 -o ServerAliveCountMax=3), including the newly-created-files case, and reports stable directory listings and file editing (#338).

Refs: #338, #371, #211