Warn when the checkpoint random states cannot be restored

[CJstate]

What does this PR do?

Fixes #4283.

load_accelerator_state() restores the RNG state inside a try/except, and reported a failure with logger.info("Could not load random states"). That message is below the effective log level of a default setup: accelerate.checkpointing has no level of its own, so logging inherits WARNING from the root logger and the record is dropped before it reaches any handler. A checkpoint whose RNG file is missing, truncated, or unreadable therefore resumed with no output at all, silently using different random numbers (and a step of 0, since step is stored in the same file) than the interrupted run.

This PR reports the failure at WARNING instead, on every process (each rank restores its own file), and includes the checkpoint path and the underlying error:

input_rng_file = input_dir.joinpath(f"{RNG_STATE_NAME}_{process_index}.pkl")
try:
    states = load(input_rng_file)
    ...
except Exception as e:
    logger.warning(
        f"Could not load the random states from {input_rng_file}: {e}. Training will resume, "
        "but the random number generators were not restored, so this run may not reproduce "
        "the interrupted one.",
        main_process_only=False,
    )

Resuming from a checkpoint without RNG state still works, it is just not hidden anymore.

Before / after, on the reproduction from #4283

Using the script attached to the issue, unmodified:

# before
RNG restored: False
RNG diverged: True
override_attributes: {}
effective log level: 30          # WARNING, so the INFO message was never emitted
                                 # ... no log line at all

# after
RNG restored: False
RNG diverged: True
override_attributes: {}
effective log level: 30
LOG[WARNING] accelerate.checkpointing: [RANK 0] Could not load the random states from
.../random_states_0.pkl: Weights only load failed. ... Training will resume, but the random
number generators were not restored, so this run may not reproduce the interrupted one.

Note about prior art: #4308 reached the same conclusion (this is the same fix, expressed independently). It was closed without review on 2026-09-25, in the same batch of PRs as #4285, #4239 and ~13 others, and the failure is still present on main. Since #4283 is still open, this PR restores the fix.

Tests

Three regression tests in tests/test_state_checkpointing.py::RandomStateRestoreTest:

• test_unreadable_rng_state_warns: save a checkpoint, corrupt random_states_0.pkl, resume → exactly one WARNING naming the file, and resuming still returns.
• test_missing_rng_state_warns: same for an absent RNG file.
• test_readable_rng_state_restores_without_warning: a healthy checkpoint loads with no warning, restores Python/NumPy/PyTorch RNG state exactly, and restores step.

Verified on Windows 11 / Python 3.13 / PyTorch 2.9.1:

• Before the fix (git stash of src/accelerate/checkpointing.py): 2 failed, 1 passed — both failures are AssertionError: no logs of level WARNING or higher triggered on accelerate.checkpointing.
• After the fix: 3 passed.
• The whole file: 21 passed (no other test relies on the INFO message).
• ruff check and ruff format --check (0.13.1, the version pinned in setup.py) pass on both files.

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline, Pull Request section?
• Was this discussed/approved via a Github issue or the forum? Please add a link
  to it if that's the case. → [Bug] RNG state restoration failure swallowed silently — resumed training diverges without warning #4283
• Did you make sure to update the documentation with your changes? No user-facing page documents this log line
  (random_states_*.pkl only appears in the FSDP usage guide as part of a checkpoint listing), so there is nothing
  to update.
• Did you write any new necessary tests?

Who can review?

@BenjaminBossan @SunMarc (core parts of the library / checkpointing)

[CJstate]

Small process note on CI: the five pull_request workflows for this branch (c66ff98d) all completed as action_required — they are queued for a maintainer to approve the run for a first-time contributor, so no check has actually reported yet.

Could someone click "Approve and run workflows" when convenient?

The description has the local before/after evidence (before: effective level 30, zero output; after: exactly one LOG[WARNING] accelerate.checkpointing: [RANK 0] Could not load the random states from ...: Weights only load failed.), including why main_process_only=False is required here.