Unified resource introspection for local and deployed environments

## Summary

The Aspire CLI should provide a consistent experience for inspecting application state whether running locally or deployed to ACA, App Service, k8s, or Docker Compose. Today, local development has rich introspection (`aspire describe`, `aspire logs`, dashboard) but deployed environments are a black box — users must leave Aspire entirely and use platform-specific tooling.

## Approach

Two existing Aspire components already solve the hard problems:

1. **Resource server** (`DashboardService` gRPC API) — provides resource state, endpoints, environment variables, health, console logs, and commands. Currently used for local AppHost <-> dashboard communication.
2. **Deployed dashboard** — already deployed alongside apps on ACA and App Service. Already receives OTLP telemetry (structured logs, traces, metrics) from all resources.

By pointing the CLI at these two endpoints — whether local or remote — the same commands work everywhere:

```
aspire describe # local (connects to running AppHost)
aspire describe --server https://... # remote (connects to deployed resource server)
aspire logs --server https://... # streaming logs from deployed resource server
```

We have already started this direction by allowing the CLI to connect to standalone dashboard instances.

## What the resource server gives us today

The `DashboardService` gRPC API (`dashboard_service.proto`) already exposes:

| RPC | Capability |
|-----|-----------|
| `WatchResources` | Full resource state — name, type, state, URLs, env vars, health reports, properties, relationships |
| `WatchResourceConsoleLogs` | Streaming console logs per resource |
| `ExecuteResourceCommand` | Run commands on resources (restart, stop, custom) |
| `GetApplicationInformation` | Application identity |

This is platform-agnostic. ACA, App Service, Docker Compose, k8s — all implement the same contract.

## What this enables

### For users
- `aspire deploy` -> `aspire describe --server ` -> see health and URLs -> `aspire logs --server myapi` -> diagnose issue -> fix -> `aspire deploy` -> `aspire destroy`
- One set of commands, same mental model, local or deployed

### For agents (Copilot, MCP tools)
- Agents can deploy, inspect, diagnose, and teardown without leaving the editor
- Structured gRPC responses are machine-readable
- Completes the agent-operated application lifecycle: run -> deploy -> inspect -> troubleshoot -> destroy

## Open questions

### Discovery and connection
- `--server ` is the explicit path, but can we auto-discover from deployment state?
- The resource server endpoint needs to be publicly accessible (or tunnel-able) on the deployed environment
- Should deployment state persist the endpoint URL locally so `aspire describe` can auto-connect?

### Authentication
- Local resource server uses API keys / no auth
- Deployed dashboard uses browser-based auth today
- CLI needs a token-based auth path for remote connections — managed identity? Azure AD token? API key provisioned at deploy time?
- How does an agent authenticate?

### Scope for v1
- Which commands need to work remotely first? (`describe` and `logs` seem highest value)
- Should `aspire destroy` (#13013) go through `ExecuteResourceCommand` or be a separate flow?

## Related work
- #13013 — `aspire do cleanup` / teardown
- CLI already supports connecting to standalone dashboard instances
- Dashboard is deployed by default on ACA and App Service environments