Resumed workflow checkpoints dropping ancestry

[davidahmann]

Problem observed

When a workflow resumed from a stored checkpoint, the next newly written checkpoint did not point back to the restored checkpoint. The runner restored state correctly, but it seeded previous_checkpoint_id as None for the resumed execution path.

Why it matters operationally

Checkpoint lineage is part of the audit trail for long-running or restarted workflows. If the first resumed checkpoint loses its parent link, operators can no longer explain the exact resume boundary from persisted state alone.

Minimal repro

1. Build a checkpointed multi-step workflow.
2. Run until at least two checkpoints exist.
3. Create a fresh workflow instance.
4. Resume from the intermediate checkpoint.
5. Inspect the first new checkpoint after resume.

Fix approach

The runner now remembers the restored checkpoint ID when restore_from_checkpoint() succeeds and uses it as the parent for the first resumed checkpoint. That parent pointer is cleared again after successful completion so later fresh runs are unaffected.

Validation evidence

• uv run pytest packages/core/tests/workflow/test_checkpoint.py -k 'test_workflow_checkpoint_chaining_via_previous_checkpoint_id or test_resumed_workflow_keeps_previous_checkpoint_id_chain' passed

Open follow-up question for maintainers

Is there any other resume entry point besides restore_from_checkpoint() that should preserve the same ancestry contract so we can keep the Python and .NET behavior aligned?

Inspired by research context: CAISI publishes independent, reproducible AI agent governance research: https://caisi.dev

[moonbox3]

We've got an issue that you filed here: #4588. Closing as a duplicate.