Python: Add reset() to workflow

[ShiyunXu]

Motivation & Context

When a workflow is hosted as an agent (e.g. in a Foundry hosted-agent session), the workflow instance is built once when the session starts. A new interaction that doesn't carry a conversation/previous-response id should start a fresh run without any residual state from prior interactions. Today that requires rebuilding the workflow from the builder, which isn't possible when the instance is long-lived.

This adds Workflow.reset(), which restores a workflow instance to its captured initial state so the same instance can be reused for a clean run.

Description & Review Guide

This is the next slice of breaking down microsoft#6407 into smaller PRs (following the runner/workflow refactor and the per-executor serialization PRs).

• What are the major changes?

  • Add Workflow.reset(). It restores the instance to an in-memory baseline checkpoint captured once per instance ({"kind": "initial_in_memory"}) via _ensure_initial_checkpoint(). The baseline is captured lazily just before the first run (or on first reset() if that comes first), so it always reflects the pristine just-built state. reset() is rejected with WorkflowException while a run is active.
  • Harden Runner.capture_checkpoint_object() to accept optional metadata and to reject capture while in-flight executor messages are present, raising WorkflowCheckpointException. Mid-superstep message state is not a clean, resumable baseline; capture is only valid when the runner is quiescent. Pending request_info events are intentionally not blocked, since idle-with-pending-requests is a stable point.

• What is the impact of these changes?

  • A long-lived workflow instance can be reset between runs instead of rebuilt. No public API removals; reset() is additive.
  • capture_checkpoint_object() now enforces the quiescence precondition it always implied.

• What do you want reviewers to focus on?

  • The baseline-capture timing (before first run vs. first reset()) and the reset() active-run guard.

Related Issue

Part of the microsoft#6407 breakdown.

Fixes #

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.