Tracking: making autonomous inner-loops a first-class scenario inside the AppHost

_Context: following a working session with the Aspire team (@maddymontaquila, @davidfowl, @DamianEdwards, @joperezr) on agent-driven inner loops on Aspire. Filing the cohesive vision plus the concrete pieces it needs._

There's a pattern we keep building toward: an autonomous orchestrator that lives *in* the Aspire graph and drives the app it's part of — edit a service → rebuild → restart just what changed → re-run the acceptance test → repeat, recovering on its own when the stack degrades. One `aspire run` brings up the services **and** the thing that drives them, with discovery and telemetry for free. We do this today for Azure Chaos Studio but with a lot of external scaffolding the platform could absorb.

This is an umbrella to track the pieces. None are huge on their own; together they make the inner-loop a supported scenario rather than a stack of workarounds:

- **Warm, targeted recovery** — restart a resource + its dependents in dependency order, await healthy, leave the rest warm (the emulators are the expensive part — don't cold-start what didn't change). Tracked at #18280.
- **In-graph orchestrator that survives restarting its peers** — a node that drives lifecycle without being torn down when the subgraph it controls restarts. The control surface mostly exists (`ResourceCommandService`, `ResourceNotificationService.WatchAsync`); the lifecycle-decoupling is the gap. Adjacent to the lifecycle model in #17722. Filed as #18545.
- **Fault injection at the proxy layer** — deterministic latency/error/drop on service edges for resilience testing, ideally native to the proxy DCP already owns. *(discussion, later)*
- **A workflow/DAG view for an in-graph orchestrator** — the dashboard already renders a *resource* graph; what's missing is letting a resource surface its own internal workflow DAG + live step state (which step ran, what's LLM vs deterministic, where it's stuck). We currently use a forked Microsoft Agent Framework DevUI for this; a per-resource custom view in the dashboard would replace the fork. *(discussion, later)*

Mostly want to validate the overall direction and whether each piece is worth a focused issue, or folds into work already in flight (#18280, #17722). Happy to drive any of them.

Start by reading the existing ResourceCommandService and ResourceNotificationService.WatchAsync control surfaces, then review the related issues #18280, #17722, and #18545. This umbrella issue has no single implementation target; done means validating the direction and turning the proposed pieces into focused, actionable issues.

Written by the indexing model from the issue text.