Fix imfs constant

[Yaxuan-w]

Resolves #204

Grates are compiled to wasm32-wasip1 target but glibc has different constant definitions.

[Blzzxrd]

I think the linkat and unlinkat failures from #204 might still remain here because both tests use flags set to 0, so changing LIND_AT_SYMLINK_FOLLOW and LIND_AT_REMOVEDIR would not affect those cases.

[Yaxuan-w]

@Blzzxrd

Good catch! You're right that the constant change alone doesn't affect the flags=0 paths.

The linkat/unlinkat failures in #204 actually had a different root cause: glibc's linkat.c in lind-wasm wasn't using make_legacy_syscall, so it always returned 0 without ever issuing the syscall. That's why "linkat creates hard link" appeared to pass while the subsequent open and unlinkat failed with ENOENT (errno=2, not EINVAL). The hard link was never actually created. That's fixed separately by Lind-Project/lind-wasm#1334, which is why those cases pass when I run the tests locally with that branch.

What this PR fixes is the constant mismatch itself: the grate is compiled for wasm32-wasip1, so libc::AT_* resolves to WASI values (AT_SYMLINK_NOFOLLOW=0x1, AT_REMOVEDIR=0x4, AT_SYMLINK_FOLLOW=0x2), while Lind's glibc passes Linux values (0x100/0x200/0x400). This directly fixes the fstatat nofollow sees symlink failure (0x100 & 0x1 == 0, so AT_SYMLINK_NOFOLLOW was silently treated as follow), and it also prevents spurious EINVALs on the non-zero-flag paths, e.g. the lind-wasm unit tests call unlinkat(..., AT_REMOVEDIR) and linkat(..., AT_SYMLINK_FOLLOW), both of which would be rejected with the old WASI-valued constants.

[gittuf-app-beta]

Observed review from Blzzxrd+121839032 (@Blzzxrd)

[lionne99]

Looks good!

[gittuf-app-beta]

Observed review from lionne99+90272590 (@lionne99)