Setting log_directory to /dev/null can cause mesa to fail

**The bug**
setting a directory such as log_directory to /dev/null can cause mesa to fail or output errors when attempting to save to null file.

**Reproduce**
1. use a copy of $MESA_DIR/star/test_suite/make_zams (or _most_ other test_suites)
2. add `log_directory='/dev/null'` into `&controls` section of inlist_zams
3. clean, make, and run the make_zams test suite
4. reach "finished doing relax num steps"
5. See errors: "failed to open /dev/null/history.data" and "failed to create zams.mod when running inlist_zams_header"

**Expected behavior**
MESA exits safely with no fail or error condition. This would be unique to using /dev/null since it is intended for cases where a program is supposed to give an output without issue. Files would not "fail" to be created since /dev/null would allow MESA to think the files were saved. A test_suite like 1M_pre_ms_to_wd would still fail when it attempts to load a .mod file that was never saved.

**Versions**
- MESA version: r25.12.1
- MESA SDK version: mesasdk-x86_64-linux-25.12.1
- OS: RHEL 9.7 & Fedora Workstation 43

**Additional context**
This is more of a feature request since it would primarily be used in a debugging or testing phases when a terminal output is enough, but it would helpful to avoid adding a bunch of controls to the inlist to turn off the logs or other directories. Using /dev/null would also be more natural for new MESA users that are already familiar with a UNIX system.

Start with the $MESA_DIR/star/test_suite/make_zams test suite and its inlist_zams controls section, then reproduce the issue using log_directory='/dev/null'. Done means the run reaches completion without errors when output targets /dev/null, while cases that later require an unavailable .mod file remain understood and tested.

Written by the indexing model from the issue text.