fix: remove rightsBase write check from fdOpen permission guard

[luchiniatwork]

Summary

WASM commands with read-only permission tier (ls, find, stat, cat, etc.) fail with EACCES when opening directories for reading.

Problem

The fdOpen permission guard in packages/posix/src/kernel-worker.ts treats RIGHT_FD_WRITE in rightsBase as write intent:

const hasWriteIntent = !!(oflags & 0x1) || !!(oflags & 0x8) || !!(fdflags & 0x1) || wantsWrite;

In WASI, rightsBase is a capability advertisement, not an intent declaration. WASI runtimes (specifically Rust's wasi-libc used by uutils-coreutils) routinely request broad rights including RIGHT_FD_WRITE even for purely read-only operations like opendir(). The runtime requests the maximum set of capabilities the file descriptor could need, and the host is expected to narrow them — not reject the open entirely.

Fix

Remove || wantsWrite from the hasWriteIntent condition. Actual write intent is already correctly captured by:

• oflags & 0x1 — O_CREAT (create file)
• oflags & 0x8 — O_TRUNC (truncate file)
• fdflags & 0x1 — O_APPEND (append mode)

Why this is safe

Write restrictions are independently enforced at two other layers:

1. The kernel-level fdOpen RPC handler in driver.ts validates permissions when the open call reaches the kernel.
2. The VFS permission wrapper enforces read-only/isolated semantics at the filesystem level.
   The wantsRead/wantsWrite variables remain in the function — they are used downstream for mapping WASI rights to POSIX open flags (O_RDONLY/O_WRONLY/O_RDWR), which is a flag translation step, not a permission check.
   EOF
   )