[BUG] GraphWorkflow checkpoints can collide across workflows and loops

[shaun0927]

Describe the bug
GraphWorkflow checkpoint filenames are currently derived from the task hash and layer index only. When multiple workflows share the same checkpoint_dir and task string, they can reuse each other's checkpoint files.

The same naming scheme also ignores the loop index, so multi-loop runs can pick up stale data from a previous loop.

To Reproduce

1. Create two different GraphWorkflow instances that share the same checkpoint_dir.
2. Run the first workflow on task "shared task" so it writes checkpoints.
3. Run the second workflow on the same task string.
4. The second workflow can load the first workflow's checkpoint files because the filename namespace is the same.

At HEAD the filename pattern is effectively:

f"{sha256(task)[:16]}_layer_{layer_idx}.json"

so workflow identity and loop identity are both missing from the checkpoint path.

Expected behavior
Checkpoint filenames should include enough stable workflow identity (for example topology/name namespace) and loop index to avoid cross-workflow or cross-loop collisions while still allowing resume across restarts for the same logical workflow.

Additional context

• Confirmed locally against master (cc1667a1).
• Relevant code: swarms/structs/graph_workflow.py:1791-1816, 1993-2000, and 2493-2498.
• I verified locally that two workflows sharing the same task string resolve to the same checkpoint path and that stale checkpoint data is readable by the second workflow.
• Related feature issue/PR: [feat][GraphWorkflow] Add checkpoint_dir parameter for mid-graph persist and resume #1484 and [FEAT] Add checkpoint for long-running GraphWorkflows #1498. I did not find an existing issue covering checkpoint namespace collisions or stale replay across workflows/loops.