Enhance Aspire Graph Visualization with Communication Protocol

### 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.

_No response_

### Describe the solution you'd like

The current graph visualization in Aspire is very useful to understand resource relationships, but it could become even more powerful by including how resources communicate with each other, not just that they are connected.

In real-world distributed applications, the communication protocol between components is a crucial part of the architecture and often conveys important semantic information that is currently lost in the graph.

**Motivation**

Consider a simple application composed of:
- Frontend
- Backend
- Database

Example communication paths:

- Frontend → Backend: using HTTP protocol (or protocols such as A2A when it comes to agentic apps)
- Backend → Database: using TCP

Today, all these connections look essentially the same in the graph, even though they represent very different interaction models.

**Proposal**

1. Expose communication protocol information in the graph
- Display protocol metadata (e.g. HTTP, A2A, TCP, gRPC, etc.) on the arrows connecting resources.
- This would improve architectural clarity and make the graph more informative and self-describing.
2. Extend WithReference to declare the protocol
- Allow developers to decorate WithReference with protocol information, for example:
- `WithReference(backend, protocol: "a2a")`
- `WithReference(database, protocol: "tcp")`
3. Protocol-aware URL injection
- The selected protocol could influence how connection information is injected. The developer should handle this, to ease the burden of coding different protocols and maintaining them.
- Example:
- For standard HTTP, inject the service base URL.
- For A2A, inject the full Agent Card discovery URL, e.g.
https://myagent.localhost/.well-known/agent-card.json

**Benefits**

- Clearer visualization of system architecture and communication patterns
- Better alignment between the Aspire model and real-world distributed systems
- Enables richer, protocol-aware tooling and future extensibility
- Improves developer understanding and onboarding for complex apps

**Open Questions**

How extensible should the protocol model be (custom protocols, metadata, icons, etc.)?
Maybe we could start small, using only standard protocols (HTTP, gRPC, TCP), for which we already have information? We could later add the option to define other protocols (A2A) at apphost level in the `WithReference()` api.

### Additional context

_No response_

Start by tracing the WithReference API and the existing Aspire graph-visualization flow to find where relationship and connection metadata are represented. The scope still needs agreement on the protocol model, graph presentation, and URL-injection behavior; done would mean an implemented, tested design covering those decisions.

Written by the indexing model from the issue text.