fix(fabric): raise on CPU tensor passed to all_reduce in non-CPU setup (#21530)

[GudeJunge]

What does this PR do?

Fixes #21530

Motivation & Context:
As reported in #21530, passing a CPU tensor to Fabric.all_reduce while running on a Multi-GPU setup (or even on Single-GPU setup) results in unintuitive behavior (perceived as a "silent failure"). Technically, the backend silently moves a copy of the tensor to the device for reduction, leaving the original CPU tensor completely untouched. This leads to silent logic errors in user code, especially during CPU-offloading workflows.

Changes introduced:

• Added a validation check inside Fabric.all_reduce: if the current fabric.device is not CPU, we explicitly verify that the passed tensors are not on the CPU.
• Raises a clear, actionable RuntimeError advising the user to move the tensor to fabric.device first.
• This constraint applies regardless of the world size to ensure a consistent API contract and "fail-fast" behavior.
• Updated the docstring to document this constraint.
• Added a mock-based test in test_fabric.py to ensure the validation logic works correctly.

Breaking Changes:
Bugfix (yes?), User scripts that previously passed CPU tensors to all_reduce on non-CPU devices survived due to the silent failure. These scripts will now explicitly fail with a RuntimeError.

Before submitting

• Was this discussed/agreed via a GitHub issue? (not for typos and docs)
• Did you read the contributor guideline, Pull Request section?
• Did you make sure your PR does only one thing, instead of bundling different changes together?
• Did you make sure to update the documentation with your changes? (if necessary)
• Did you write any new necessary tests? (not for typos and docs)
• Did you verify new and existing tests pass locally with your changes?
• Did you list all the breaking changes introduced by this pull request?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review

Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

Reviewer checklist

• Is this pull request ready for review? (if not, please submit in draft mode)
• Check that all items from Before submitting are resolved
• Make sure the title is self-explanatory and the description concisely explains the PR
• Add labels and milestones (and optionally projects) to the PR so it can be classified

---

📚 Documentation preview 📚: https://pytorch-lightning--21573.org.readthedocs.build/en/21573/