DevUI aggregator (Aspire.Hosting.AgentFramework.DevUI) does not surface workflow topology from backends

## Background

`Aspire.Hosting.AgentFramework.DevUI` provides an out-of-process aggregator that runs inside the AppHost and proxies the OpenAI Responses/Conversations APIs to one or more backend agent services. Agents are declared explicitly at the AppHost level via `WithAgentService(agents: [...])`, and the aggregator builds a single `/v1/entities` listing from that metadata.

The sibling in-process DevUI in [`Microsoft.Agents.AI.DevUI`](https://github.com/microsoft/agent-framework/tree/main/dotnet/src/Microsoft.Agents.AI.DevUI) (mounted via `app.MapDevUI()` inside an agent service) discovers **both** `AIAgent` and `Workflow` instances from the agent service''s DI container, and renders workflow topology — executors plus `edge_groups` — so multi-agent handoff workflows are visualized as a graph in the UI.

## Problem

When a backend agent service uses Microsoft Agent Framework''s handoff/workflow APIs (e.g. `builder.AddWorkflow(name, factory)` followed by `AddAIAgent(name, sp => sp.GetRequiredKeyedService(key).AsAIAgent(...).CreateFixedAgent())`), the Aspire DevUI aggregator only sees the wrapper `AIAgent` declared in `WithAgentService(agents: [...])`. The workflow''s internal executors and handoff edges are invisible — the UI shows a single node instead of the multi-specialist topology.

This means apps that adopt the Aspire DevUI integration lose the workflow-graph visualization that''s available with the in-process DevUI. For multi-agent orchestration scenarios (which are arguably the most interesting case for a debug UI), users have to choose between Aspire-native wiring and DevUI''s topology view.

## Proposed enhancement

Allow the aggregator to surface workflow topology from backends in one of these ways (in increasing order of work):

1. **Backend-supplied entities endpoint** — define a convention where backends that opt in expose `/v1/entities` (or similar) with workflow topology in the same shape used by the in-process DevUI. The aggregator would prefer backend-supplied listings over the explicit `agents: [...]` metadata when present, and prefix entity IDs as it does today. `MapDevUIEntities()` (or equivalent) could be added to `Microsoft.Agents.AI.Hosting` so a backend opts in with one line.
2. **Workflow metadata in `WithAgentService`** — extend `WithAgentService` to accept `Workflow` descriptors alongside agents, so AppHost authors can declare topology declaratively. Lower fidelity than option 1 but doesn''t require a new backend contract.
3. **Pass-through of arbitrary entity types** — generalize the aggregator''s entity model so any future entity kind in `Microsoft.Agents.AI.DevUI` flows through automatically.

Option 1 seems most aligned with how the in-process DevUI already works and would keep the two implementations consistent.

## Repro / context

- Package: `Aspire.Hosting.AgentFramework.DevUI` 1.8.0-preview.260528.1
- Companion in-process package: `Microsoft.Agents.AI.DevUI` 1.8.0-preview.260528.1
- Confirmed by switching a sample app from the aggregator to in-process `MapDevUI()`: same workflow registration, but only the in-process variant renders the executor/edge graph for a 5-specialist handoff workflow.

## Workaround

Drop `Aspire.Hosting.AgentFramework.DevUI` and use `Microsoft.Agents.AI.DevUI`''s `app.MapDevUI()` directly inside the agent service. Loses the AppHost-level aggregation across multiple services.

cc @ each-package-owner

Start by comparing the entity handling in Aspire.Hosting.AgentFramework.DevUI with Microsoft.Agents.AI.DevUI, especially the /v1/entities flow, MapDevUI(), and WithAgentService(agents: [...]). Trace how workflow executors and edge_groups are discovered and represented, then determine which proposed backend or AppHost integration fits. Done means the Aspire aggregator can surface the backend workflow topology while retaining aggregation across services.

Written by the indexing model from the issue text.