Expose sanitized workflow DAG definitions for visualization, debugging, and reuse

> Please provide us with the following information:
> ---------------------------------------------------------------

### This issue is for a: (mark with an `x`)
```
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
```

### Minimal steps to reproduce
> 1. Start a Dynamic Workflow that produces a validated DAG.
> 2. Inspect the application workflow status/list APIs.
> 3. Observe that the normalized DAG is only retained as Durable orchestration input and is not available through a safe application API or stable application URL.

### Any log messages given by the failure
> N/A

### Expected/desired behavior
> Define a versioned, sanitized workflow-definition contract and an authenticated application API for retrieving a workflow DAG without exposing raw Durable orchestration input.
>
> The contract should support visualization and customer debugging now, while remaining reusable by a future deterministic **Static Workflow** capability in which a skill or other authoring experience generates a validated DAG from a prompt and persists it independently of any execution instance.
>
> Suggested design requirements:
>
> - Introduce a shared immutable definition model (for example, `WorkflowGraphDefinition`) with a schema version, nodes, dependencies/edges, node type and safe authoring metadata, source (`dynamic` or `static`), and a definition digest.
> - Keep reusable definition identity/revision separate from execution instance identity, runtime inputs, status, history, and outputs.
> - Provide an owner-authorized endpoint such as `GET /agents/{slug}/workflows/{workflow_id}/definition`; do not add the full DAG to workflow list responses.
> - Return only explicitly allowlisted graph metadata. Raw Durable input must not be proxied because task arguments, Sub Agent prompts, policy data, and customer content may contain secrets or sensitive data.
> - Define field-level omission/redaction rules and safe error behavior when the orchestration input is unavailable, malformed, purged, or from an unsupported schema version.
> - Preserve current agent/session ownership checks. A workflow ID must not be treated as an authorization credential, and Function keys or other credentials must never be embedded in links.
> - Treat same-user retrieval and third-party sharing as separate security surfaces. Any externally shareable URL requires an explicit authorization design (for example, Entra authorization or a scoped, revocable, expiring capability), not an automatically public bearer URL.
> - Avoid serializing the DAG into query parameters. Support explicit sanitized JSON export if portable sharing is required.
> - Account for Durable retention/purge semantics: instance-backed retrieval is sufficient for short-term debugging, but reusable or durable sharing requires a versioned definition store independent of Durable history.
> - Reuse the same validator/serializer across Dynamic Workflow execution, graph retrieval, visualization, and future Static Workflow definitions so the two workflow modes do not drift.
> - Keep this application-owned graph-definition link separate from the Durable Task Scheduler dashboard link proposed in #153. Do not turn the DTS endpoint override into a generic arbitrary-URL configuration surface.
>
> This work is intentionally outside the initial DTS dashboard-links scope in #153 and should follow the medium+ FRD process before implementation. It refines the broader “versioned reusable workflow definitions” roadmap item in #90.
>
> Acceptance criteria should include authorization/ownership tests, credential and content-redaction tests, unsupported/purged input behavior, content-security and URL tests, Dynamic Workflow compatibility, and a design proving that Static Workflow definitions can use the same versioned graph contract without depending on a Durable execution instance.

### OS and Version?
> All supported deployment environments, including Azure Functions with Azure Storage or managed Durable Task Scheduler and local development with the DTS emulator.

### Versions
> Current `main` / future release.

### Mention any other details that might be useful

> Related: #90 (Dynamic Workflows roadmap) and #153 (safe DTS dashboard links). This issue should not introduce generic runtime observability or expose Azure Storage dashboard links.
>
> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Start with the medium+ FRD process and read related issues #90 and #153 to understand the existing workflow and dashboard-link boundaries. Define the scope around a versioned sanitized graph contract and authenticated retrieval, then use the listed acceptance criteria to verify ownership, redaction, unsupported or purged inputs, URL safety, Dynamic Workflow compatibility, and future Static Workflow reuse.

Written by the indexing model from the issue text.