No way to set or read file permissions, so programs cannot protect or verify the secrets they write

[logbie]

Summary

The filesystem stdlib has no way to set or read a file's permissions. A WFL
program that writes a sensitive file cannot restrict access to it, and cannot
verify that it is restricted.

Filesystem builtins available (src/stdlib/filesystem.rs):

copy_file      count_lines   delete_file    file_mtime    file_size
glob           is_dir        is_file        list_dir      makedirs
move_file      path_basename path_dirname   path_exists   path_extension
path_join      path_stem     recursive_dir  remove_dir    remove_file
rglob

None of these touch mode or ownership. set_permissions appears in the WFL
source only inside WFL's own internal tests (src/debug_report.rs,
src/logging.rs), never exposed to programs.

Why this matters

WFL has a credible security story otherwise — Argon2, scrypt, PBKDF2, HMAC,
constant-time comparison, CSRF tokens. Those are the building blocks of programs
that handle secrets, and programs that handle secrets write them to disk.

Concretely: a config file holding an API key must not be world-readable. Today a
WFL program can create that file but cannot make it 0600, and cannot check
whether it is. The best available mitigation is external — set UMask=0077 in
the systemd unit and rely on the process environment — which works but is
invisible to the program and unverifiable from inside it.

That second half matters as much as the first. Even with a correct umask, a WFL
program cannot implement the common and reasonable check "refuse to start if the
config file is group- or world-readable," because it cannot read the mode.

Request

Two operations, in rough priority order:

1. Read a file's mode — enables refuse-to-start checks even before writes
   are supported.
2. Set a file's mode.

Sketch:

store mode as file_mode of "config.json"     // e.g. "0600"
set file_mode of "config.json" to "0600"

Portability note

Unix modes do not map cleanly onto Windows ACLs, which is presumably part of why
this is absent. A reasonable narrower scope: implement real semantics on Unix,
and on Windows either map to a documented approximation or raise a clear
"unsupported on this platform" error. An explicit error is far better than the
current situation, where the operation cannot be expressed at all and the
security property silently depends on how the process happened to be launched.

A useful middle path, if full mode support is unattractive: an "owner-only"
option on file creation, which covers the dominant use case without exposing a
POSIX-shaped API on every platform.