REMD submission flow
====================

When ``run.remd`` is enabled, production jobs are submitted per-component rather than
per-window. REMD input files are always prepared; the toggle only controls whether they
are submitted.
Key behaviours:

* Under ``fe/<comp>/remd/``, runtime groupfiles are generated by ``run-local-remd.bash``
  (``mdin.in.remd.groupfile``; a ``mdin.in.remd.current`` copy is kept for compatibility).
  Each window also gets a fresh ``mdin-remd-current`` derived from ``mdin-remd-template``.
  A minimisation groupfile (``mini.in.remd.groupfile``) is still prepared during setup.
* ``run-local-remd.bash`` computes the exchange count from the remaining
  ``total_steps`` and ``remd_nstlim``, runs a single REMD segment, then exits. It
  tracks completion with ``FINISHED``/``FAILED`` sentinels and expects window folders
  ``<comp>00/`` etc. for restarts (``eq.rst7`` → ``md-current.rst7``/``md-previous.rst7``).
* The Slurm submit script for REMD is ``SLURMM-BATCH-remd`` sitting in the component folder.
  Submissions use this script directly and rely on the same sentinels above.
* Job names are formatted as ``fep_<system_root>_<comp>_remd`` so CLI reporting
  (:func:`batter.cli.jobs_cmds.report_jobs`) can classify them with stage ``remd``.

Keep these conventions in mind if modifying the REMD pipeline or backends.