fix: fsmount data loss, deadlock, and locking bugs

[childish-sambino]

Fixes from an audit of the fsmount package, one commit each:

• The upload sweeper computed idle time from a zero timestamp for write sessions whose upload hasn't started yet (uploads begin at flush/release), so time.Since(zero) exceeded every timeout and the sweeper cancelled live sessions, deleting their working copies, on its first 10-minute tick. Silent data loss for any file held open for write across a tick.
• flags.IsReadOnly compared the whole flag word to zero. Linux forces O_LARGEFILE (0x8000) into every open from 64-bit userspace, so all read opens were classified as writes: reading a file without the w permission returned EACCES, and every read open acquired an exclusive remote lock. It now masks the POSIX access mode plus write-implying bits (O_CREAT, O_TRUNC, O_APPEND).
• RemoteFs.Destroy held lockMapMutex while calling unlock, which re-acquires the same mutex. Unmounting with any held file lock deadlocked. It now snapshots the map before unlocking.
• listDir read lockMap without the mutex, racing lock acquisition on another FUSE dispatch thread (fatal concurrent map read and write).
• Linux LocalFs.Getattr lstat'd the raw FUSE path instead of the sandbox path (fq was computed but only logged), so locally-stored files always returned ENOENT. The darwin twin already used fq.
• Windows LocalFs.Getattr emitted Go FileMode bits instead of POSIX S_IFMT, so locally-stored directories were reported with S_IFMT == 0 and Explorer treated them as zero-type files.

This package needs fuse.h to compile, which my machine doesn't have, so verification here was GOOS=windows go build/go vet (clean) plus a new IsReadOnly test case that needs CI to execute.

🤖 Generated by Quad tha God