[Core] Consume SleepModeBackend capability flags in the worker suspend/resume path

[matteso1]

Prior art / provenance

• [Core] Pluggable sleep-mode backend abstraction (RFC #34303) #44074 (merged) introduced the pluggable SleepModeBackend with capability flags (preserves_communicators, preserves_graphs_with_communicators, preserves_compiled_artifacts, supports_durable_storage) — but the flags currently have zero in-tree consumers: Worker.sleep/wake_up still assume the cumem world where communicators and captured CUDA graphs survive suspend untouched. The preserves_communicators docstring even says "the executor must re-initialize them on resume" — nothing does.
• RFC [RFC]: CUDA Checkpoint/Restore for Near-Zero Cold Starts #34303 phases in checkpoint-style backends (cuda-checkpoint / CRIU; @elizabetht's [Core] CUDA Checkpoint/Restore — Phase 1: C Extension, Python Wrapper, Worker Methods #37921/[Core] CUDA Checkpoint/Restore — Phase 2: Engine/Executor/API Integration #37925 lineage) that break both assumptions. Today cuda-checkpoint cannot restore a TP>1 vLLM server at all (cuda-checkpoint cannot restore 2-GPU vLLM server process NVIDIA/cuda-checkpoint#27) because comm state does not survive suspend.
• NVIDIA is building the layer below vLLM: NCCL contrib/nccl_checkpoint and FlashInfer RFC [RFC] Checkpoint lifecycle APIs for CUDA-graph-stable communication workspaces flashinfer-ai/flashinfer#3791 (@galletas1712) keep CUDA graphs valid across checkpoint while the uncheckpointable parts of comm state are destroyed/recreated.
• The design question "who owns comm destroy/recreate — the backend or the executor around it?" was discussed with @galletas1712 (NVIDIA Dynamo): each communicator owns destroy/recreate inside suspend()/resume(); the worker only sequences the calls. This PR encodes that contract on the vLLM side so the seam is ready before the comms-library support ships.

What this adds

1. GroupCoordinator.prepare_for_suspend() / reinit_after_resume() — the communicator-owned lifecycle hooks. Single-member groups hold no peer state and no-op (so a TP=1 checkpoint backend works today). Multi-member groups fail loudly with a pointer to the required comms-library support, instead of resuming into corrupt comm state.
2. prepare_communicators_for_suspend() / reinit_communicators_after_resume() in parallel_state — sequencing only (subgroups before world on suspend, world first on resume), mirroring destroy_model_parallel's group handling.
3. Worker.sleep/wake_up consume the flags — a backend reporting preserves_communicators() == False gets teardown before suspend() and rebuild after resume(); if it also reports preserves_graphs_with_communicators() == False, wake fails loudly rather than replaying captured graphs that launch into destroyed comm state (discard+recapture is follow-up work; a suspended engine is not serving, so re-arming is an init-time-style operation consistent with the capture-at-init-only constraint).

What this deliberately does not do

• No CudaCheckpointBackend — that lands separately on the [Core] Pluggable sleep-mode backend abstraction (RFC #34303) #44074 factory (being driven by @elizabetht; this PR is the seam it plugs into).
• No multi-member comm rebuild — that strictly requires changes in the comms libraries themselves (nccl_checkpoint, [Doc] Fix vLLMEngine Doc Page #3791); the hooks define where it lands and fail loudly until then.
• No graph discard+recapture mechanism — the wake-path branch exists and fails loudly; the mechanism is follow-up.

Behavior

No change for existing users: the default cumem backend reports preserves_communicators() == True, so every new branch is unreachable on today's configurations. Unit tests cover the orchestration order (teardown before suspend, rebuild after resume, graph invalidation after rebuild), the untouched cumem path, and single- vs multi-member hook behavior.

Open questions for reviewers

1. preserves_graphs_with_communicators is a classmethod, but graph validity is workload-dependent (a graph survives checkpoint iff nothing comm-device-side was captured into it — FlashInfer-path capture sets pass today, DeepEP does not until NCCL checkpoint learns graphs). Should the flag become instance/capture-aware, or is conservative-False per backend acceptable until then?
2. Group enumeration mirrors destroy_model_parallel's explicit globals (_TP/_DCP/_PCP/_PP/_DP/_EP/_EPLB + _WORLD). Should it iterate the _groups registry instead to cover ad-hoc groups?
3. Once discard+recapture exists, should it live in the worker (a compile_or_warm_up_model subset) or as a reset API on the graph-capture manager?

[galletas1712]

Let's introduce these APIs in device_communicators as well, since there are other comms aside from NCCL (flashinfer, custom allreduce, etc) that need to be suspended.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @matteso1.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork