Fix I6 filename/index overflow in multiscale Ac, field-snapshot, restart-dir and k-expand naming

[MZKC]

Summary

Fixed-width integer edit descriptors used to build filenames and restart/checkpoint directory names in src/io and src/ms. Two classes:

1. i6.6 filename/index overflow — a 6-digit zero-padded step/iteration counter overflows to ****** once the counter reaches 1,000,000, silently colliding every subsequent frame onto one filename. Real functional bug for long runs (nt >= 1e6).
2. Format / output-list mismatches — write(x,'(A,I6.6,A)') trim(...) : a format with an I6.6 (and trailing A) edit descriptor but only one character output item, i.e. no integer argument for the I6.6. This is nonconforming Fortran; today it happens to produce the intended x = trim(...) via format reversion (format control terminates at the first data-edit descriptor with no matching item), so it is not currently observed to fail, but it is fragile and should be corrected.

1. Multiscale Ac field-snapshot filename overflow (src/ms/main_ms.f90) — class 1

write(file_ac_data, '(a,a,"_Ac_",i6.6,".data")') ..., itt

For itt >= 1,000,000 the field overflows to Ac_******.data, so every frame for steps 1e6 ... nt collides on the same filename and overwrites the previous one — the late-time field snapshots of long-pulse multiscale runs are silently lost. Fixed by widening to i0.6 (identical 6-digit zero-padding below 1e6, grows automatically past it). Logic/compile-verified (no nt >= 1e6 live run in this PR).

2. Real-space snapshot filenames in write_field.f90 — class 1

The RT step counter itt is formatted with i6.6 in nine snapshot filename builders (_dns_, _dnsdiff_, microscopic current / magnetization / spin-current, _elf_, _Exsta_, and the per-step ion / field .bin). Same itt >= 1e6 overflow as (1). Widened to i0.6. The MPI-rank id_r writes are intentionally left at i6.6 (bounded by nproc, not a growing step counter).

3. Checkpoint-directory iteration index (src/io/checkpoint_restart.f90) — class 1

generate_checkpoint_directory_name formatted the checkpoint iter with i6.6; widened to i0.6 (same overflow class; would bite nt >= 1e6 runs with periodic checkpointing).

4. Format / output-list mismatches — class 2

generate_restart_directory_name (src/io/checkpoint_restart.f90) and three copies in the k-expand restart helpers (src/io/main_dft_k_expand.f90:346, src/io/main_dft_k_expand_slice.f90:320,340) all built a directory string with write(gdir,'(A,I6.6,A)') trim(...) — three edit descriptors, one output item, no integer for the I6.6. Replaced with the conforming write(gdir,'(A)') trim(...) (identical result, gdir = trim(basedir/odir/directory_read_data)).

Scope note (what this PR does NOT fix)

An earlier draft of this PR attributed the production RT restart-write abort (data_for_restart_rt/ left empty, MPI_File_open / CODE=1907 at the RT end-of-run checkpoint) to the generate_restart_directory_name mismatch in (4). A real-hardware GS→RT validation on the fixed binary showed that is not the cause: GS restart succeeds and the RT restart write still aborts identically with the (4) fix in place. That abort is a separate, independent bug — an uninitialized ofl%dir_out_restart passed to the RT checkpoint because initialization_rt calls init_dft with a throwaway local instead of the returned ofl — and is addressed in a separate PR. The changes here are I6-overflow fixes (real for nt >= 1e6) and format-conformance cleanups; they are not tied to that RT-restart abort.

Verification

• i0.6 behavior: 12345 -> 012345, 999999 -> 999999, 1000000 -> 1000000, 1234567 -> 1234567 (no overflow, sortable).
• (4) result unchanged: gdir = trim(basedir); callers consume gdir directly (wdir = gdir, then pdir = trim(gdir)//'rank_'...), no caller expects an appended index; no reader parses these filenames for the step index, so the widened i0.6 does not break globbing.
• Compiles cleanly on Fugaku (A64FX, mpifrtpx, --arch=fujitsu-a64fx-ea).
• GS restart write exercised successfully on the fixed binary in the validation run above (data_for_restart/ fully populated).

[jenkins-diana]

Can one of the admins verify this patch?