"Production-First" focus right from the start

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Very recently found this tool and I like it a lot. Also I don't have a ton of familiarity with this, so I might be asking for something that Aspire already provides/ plan to provide.

The current path to production relies on generating a manifest that can be consumed by tools like the Azure Developer CLI (azd) to provision and deploy resources.

While this is a great approach, the focus remains "local-first." For developers, especially those newer to cloud-native architectures, this creates a gap between the seamless "F5" development loop and the complexities of a real-world production deployment. This leads to uncertainty and friction:

- Delayed Complexity: Key decisions about production infrastructure, CI/CD, and environment-specific configurations are often postponed, leading to surprises late in the development cycle.
- High Cognitive Load: The developer must manually discover and learn the manifest-to-deployment workflow, which feels disconnected from the initial project setup.
- Lack of Visualization: There is no clear, visual representation of how the components defined in the AppHost project will map to actual cloud services in a target environment like Azure, AWS or GCP.

This creates an "uneasy feeling" where the developer is not confident how their local setup will translate to production.

### Describe the solution you'd like

I propose enhancing .NET Aspire with a "production-first" mindset, making the path to production a well-lit, visible, and integral part of the development experience from the very beginning. This approach would treat production as the default target and local development as a high-fidelity simulation of it, much like the Node.js ecosystem's philosophy around `NODE_ENV=production`.

Here are a few suggestions I can think of:

1. Production-Aware Project Scaffolding
Extend the `dotnet new` experience for Aspire. When creating a new project, the template could prompt for a target deployment environment.

```bash
$ dotnet new aspire
? What is your primary deployment target?
> Azure Container Apps
AWS ECS
Kubernetes
(Deploy manually later)
```

Based on the selection, the template would scaffold not only the Aspire project but also the necessary deployment assets. For example, if "Azure Container Apps" is chosen, it could generate:
- A pre-configured `azure.yaml` file for `azd`.
- Starter Bicep or Terraform files for infrastructure as code.
- A basic, ready-to-use GitHub Actions workflow (.github/workflows/deploy.yml) for CI/CD.

2. Deployment Visualization in the Aspire Dashboard
Enhance the Aspire Dashboard with a "Deployment Preview" or "Production Topology" view. This feature would:
- Parse the application's manifest and any available deployment configuration (e.g., azure.yaml).
- Render a visual graph of the application as it would appear in the target cloud.

This would provide immediate visual feedback on the production architecture, directly connecting the code being written to its real-world deployment.

3. Streamlined Deployment Commands
Integrate deployment initiation directly into the tooling. Once configured, a developer could intuitively run a command like `dotnet aspire deploy` command from the project root, further tightening the loop between development and deployment.

By making production considerations a first-class citizen and providing clear visualization, .NET Aspire can empower developers to build with confidence, knowing exactly where and how their application is designed to run.

### Additional context

_No response_