feat: support file-backed configuration secrets

[mvanhorn]

Extend the production environment-expansion policy so an explicitly set NAME keeps its current behavior, while an unset NAME falls back to reading the UTF-8 file named by NAME_FILE; if neither variable is available, retain the existing missing-variable failure. Apply that policy through every existing expandable-field deserializer in zerofs/src/config.rs, while updating the locked-memory expansion path in zerofs/src/secrets.rs so the encryption password is read and assembled without introducing an ordinary plaintext password copy. Treat the credential as a single textual value, removing terminal line endings as the issue's cat workaround does, and return contextual path/read/UTF-8 errors without including secret contents. ZeroFS configuration currently expands secret values only from process environment variables, while systemd credentials expose decrypted values as files beneath the credentials directory. Operators must therefore add a shell wrapper that reads each credential file and exports its contents before starting ZeroFS. The requested change should let the existing $NAME and ${NAME} configuration references consume file-backed credentials without executing shell expressions or adding provider-specific configuration keys. The issue is open and unassigned, its thread contains no active claim, and the supplied timeline and competing-PR data show no prior or in-flight implementation. With only ZEROFS_PASSWORD_FILE, AWS_ACCESS_KEY_ID_FILE, and AWS_SECRET_ACCESS_KEY_FILE set to readable credential files, load a config that references the corresponding unsuffixed variables and verify the encryption password and AWS values contain the file contents rather than the paths; With both NAME and NAME_FILE set, verify the direct environment value wins so existing deployments do not change behavior; also verify ordinary expandable fields continue to support $VAR, ${VAR}, defaults, and $$ escaping.

Fixes #559

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}