Hardcoded Fortran file-unit numbers where newunit= is already used elsewhere

[sbryngelson]

Several output routines open files on hardcoded unit numbers — some computed from a loop index (i+30, i+70, i+120), some fixed small integers (3, 1). These are collision-prone (overlapping ranges, or clashing with any library/implicit unit) and avoidable: the codebase already uses open(newunit=...) in the same files.

Hardcoded-unit sites:

• src/simulation/m_data_output.fpp: run-info open(3, ...) (L81); CoM open(i + 120, ...) (L115; close(i+120) L1618); probe open(i + 30, ...) (L145, 147; close L1629); integral open(i + 70, ...) (L156). These ranges can overlap once enough probes/integrals/CoM files exist.
• src/common/m_boundary_common.fpp: open(1, ...) at L1872, L1881, L1970, L1986 (this file has no newunit usage at all).
• src/post_process/m_data_output.fpp: open(211, ...) (L424; close L1493), open(251, ...) (L436; close L1500), open(unit=29, ...) (L803).

newunit= precedent (same/nearby files):

• src/simulation/m_data_output.fpp:987 — open(newunit=file_unit, ...).
• src/post_process/m_data_output.fpp:1129, 1137, 1389 — open(newunit=...).
• src/common/m_compile_specific.f90 — uses newunit.

Why it's friction: hardcoded units are a classic source of "file opened on a busy unit" bugs, especially the index-offset ranges that can collide as case sizes grow. The fix pattern is already established in the tree.

Fix: convert these open(<literal>, ...) calls to open(newunit=<int var>, ...) and carry the variable to the matching write/close. Changes runtime unit assignment but not file contents → golden-neutral.

---

_{Filed from a repo-wide code-cleanliness review; verified against master @ 40dde5e.}

Code references

• src/simulation/m_data_output.fpp:115 — open(i+120)
• src/common/m_boundary_common.fpp:1872 — open(1)
• src/post_process/m_data_output.fpp:424 — open(211)
• src/simulation/m_data_output.fpp:987 — newunit= precedent