Add DTS dashboard links to Dynamic Workflow chat cards

> 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. Configure Dynamic Workflows with the Durable Task Scheduler backend.
> 2. Open an agent's built-in debug chat UI.
> 3. Ask the agent to start a workflow.
> 4. Observe that the workflow card shows the runtime status, progress, and a truncated instance ID, but provides no link to inspect that orchestration in the DTS dashboard.

### Any log messages given by the failure
> N/A. This is a usability enhancement, not a runtime failure.

### Expected/desired behavior
> When a Dynamic Workflow uses DTS, its workflow card in the built-in chat UI should provide an **Open in DTS** link. Prefer a direct orchestration-instance link if DTS exposes a documented stable deep-link contract. Otherwise, open the relevant task-hub dashboard and make the full instance ID easy to copy/search.
>
> No link should be shown for the Azure Storage backend unless a separately supported dashboard target exists.

### OS and Version?
> All supported platforms. The motivating local scenario was Windows with the DTS Docker emulator and Azure Functions Core Tools v4.

### Versions
> Current `main` plus the per-agent Dynamic Workflows implementation in PR #151.

### Mention any other details that might be useful

> **Current UI**
>
> The workflow card already retains the full `workflow_id` while rendering a truncated ID, progress, terminal state, and completion notification. This gives the UI everything needed to associate a link with the correct orchestration. A screenshot from the motivating discussion shows a completed workflow card between the initial assistant response and the final result summary; the missing affordance is a link from that card to DTS.
>
> **What can be derived from existing configuration**
>
> A generic `WORKFLOW_DASHBOARD_URL_TEMPLATE` should not normally be necessary:
>
> - `host.json` identifies DTS through `extensions.durableTask.storageProvider.type: azureManaged`.
> - `storageProvider.connectionStringName` identifies the app setting containing the DTS connection string.
> - The connection string supplies the scheduler `Endpoint`.
> - `extensions.durableTask.hubName`, after app-setting expansion, supplies the task hub name.
> - For Azure DTS, the documented dashboard URL is:
> `https://dashboard.durabletask.io/?endpoint=&taskhub=`
> - For the standard local emulator, the scheduler endpoint is normally port 8080 and the dashboard is normally `http://localhost:8082`.
>
> **Proposed behavior**
>
> 1. Resolve dashboard metadata server-side; never expose the DTS connection string or authentication components to the browser.
> 2. For Azure DTS, derive the dashboard URL from the scheduler endpoint and resolved task hub name.
> 3. For the standard emulator mapping, derive the dashboard at port 8082.
> 4. Support an optional `DTS_DASHBOARD_ENDPOINT` override only for emulator/custom-network cases where the dashboard host port cannot be inferred from the scheduler endpoint. For example, the repository verifier maps container ports 8080 and 8082 independently to random host ports, so the gRPC connection string cannot reveal the mapped dashboard port.
> 5. Return only a validated safe dashboard URL/metadata to the Chat UI.
> 6. Render the workflow ID as a link or add an **Open in DTS** action on each workflow card. Use `noopener noreferrer` and open in a new tab.
> 7. Preserve the current UI unchanged when DTS is not configured or the URL cannot be derived safely.
>
> **Open design question**
>
> Microsoft documents the task-hub dashboard base URL and the dashboard's shareable-link feature, but we should confirm whether an orchestration-instance-specific route is a supported stable contract. If it is not, the first implementation should link to the task-hub dashboard and provide/copy the full workflow instance ID rather than depending on an undocumented route.
>
> **Authentication and security**
>
> - Azure dashboard access requires the user's Azure identity to have the Durable Task Data Contributor role.
> - The application must not send connection strings, managed identity details, credentials, or arbitrary unvalidated URLs to the browser.
> - Restrict derived/override URLs to `http`/`https`; consider allowing plain HTTP only for loopback emulator endpoints.
>
> **Acceptance criteria to discuss**
>
> - Azure DTS workflow cards show a task-hub dashboard link derived from existing configuration.
> - Standard emulator workflow cards show the local dashboard link.
> - Custom emulator port mappings work through a minimal optional override.
> - Azure Storage workflow cards do not incorrectly show DTS links.
> - No connection string or credential material reaches Chat UI responses or HTML.
> - Tests cover Azure, standard emulator, custom-port override, malformed settings, and non-DTS fallback.
>
> References:
> - https://learn.microsoft.com/azure/durable-task/scheduler/durable-task-scheduler-dashboard
> - PR #151

> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Read the Dynamic Workflows implementation in PR #151 and the workflow-card/Chat UI entry points; trace how host.json, connectionStringName, hubName, and the DTS endpoint are resolved. Run or add coverage for Azure, the standard emulator, custom overrides, malformed settings, and Azure Storage fallback; done means safe links render only for DTS without exposing credentials.

Written by the indexing model from the issue text.