Rollup merge of #162065 - physwkim:vxworks-set-perm-nofollow, r=ChrisDenton

std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow`

`set_permissions_nofollow` was consolidated into `sys/fs/unix.rs::set_perm_nofollow` by rust-lang/rust#160170, which dropped the `not(target_os = "vxworks")` guard the previous `sys/fs/mod.rs` implementation carried. VxWorks' libc defines no `O_NOFOLLOW` (the platform's `<sys/fcntlcom.h>` stops at `O_CLOEXEC`, and `rust-lang/libc` correctly does not bind it for `vxworks`), so building `std` for `x86_64-wrs-vxworks` now fails:

```
error[E0425]: cannot find value `O_NOFOLLOW` in crate `libc`
    --> library/std/src/sys/fs/unix.rs:1916
     |
     |             options.read(true).custom_flags(libc::O_NOFOLLOW);
     |                                                    ^^^^^^^^^^ not found in `libc`
```

`x86_64-wrs-vxworks` is tier 3 and isn't built in CI, so this wasn't caught. `set_perm_nofollow` is the only `O_NOFOLLOW` reference compiled for VxWorks — the `remove_dir_all` "modern" path already lists `vxworks` in its fallback set, and the remaining occurrences are a doc example and comments.

Unlike ESP-IDF and Horizon (which skip `O_NOFOLLOW` because their filesystems have no symbolic links), VxWorks *does* have symlinks, so it can't just drop `O_NOFOLLOW` and follow the link silently. This returns `ErrorKind::Unsupported`, matching the existing Android stub.

## `Unsupported` is the platform-correct result

Verified on-target against the shipped VxWorks 7 SDK (`wrsdk-vxworks7-qemu-1.17.0`, the QEMU BSP). VxWorks has no way to express a no-follow permission change:

- No `O_NOFOLLOW`. The only related flag is `O_NOLINK` ("open the symlink itself"), which is different semantics and not what the `open` + `fchmod` path wants.
- `fchmodat` *is* provided — by the UTILS_UNIX component in `libunix`, not core `libc` — and `AT_SYMLINK_NOFOLLOW` is defined as `0x100`. But the shipped `libunix.so` **rejects the flag with `ENOTSUP`**:

```asm
0000000000009300 <fchmodat>:            ; (dirfd=edi, path=rsi, mode=edx, flag=ecx)
    cmpl   $0x100,-0x18(%rbp)           ; flag == AT_SYMLINK_NOFOLLOW ?
    jne    9340 <fchmodat+0x40>
    mov    $0x23,%edi                   ; errno = 0x23 (35 = ENOTSUP)
    call   errnoSet
    movl   $0xffffffff,-0x4(%rbp)       ; return -1
    ...
9340:                                   ; flag == 0
    call   taskSafe
    ...  atCatPath(dirfd, path)
    call   chmod                        ; plain chmod -> follows the symlink
```

So `fchmodat(.., AT_SYMLINK_NOFOLLOW)` returns `-1`/`ENOTSUP`, and `flag == 0` degrades to `chmod`, which follows symlinks. A `fchmodat`-based implementation is not viable on this release — the platform's own `fchmodat` reports `ENOTSUP` for exactly this request, which is why `Unsupported` is correct rather than merely conservative. cc @biabbas @hax0kartik

## Build verification

On `1.100.0-nightly (908501772 2026-08-30)` + `rust-src` (stock `libc` 0.2.189):

- Before: `cargo +nightly build -Zbuild-std=std,panic_abort --target x86_64-wrs-vxworks` fails with the E0425 above (1 error).
- After this patch: the same command finishes successfully.