Support abstraction for cross-service file sharing across local dev and Kubernetes deployment

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

When developing with Aspire locally and deploying to Kubernetes, sharing files between services requires fundamentally different approaches, breaking the abstraction that Aspire provides.

Current workaround:
- **Local development**: Services running directly on the host and containers use bind mounts or direct filesystem access to share files
- **Kubernetes deployment**: Services run in containers and use PersistentVolumeClaims (PVCs) to share files

This means developers must maintain two separate configurations and understand the nuances of each deployment target.

Additional limitations:
- BindMounts are not supported by the Kubernetes publisher
- Local Docker services cannot share volumes with each other (only host bind mounts work)
- Even with ProjectResourceV2 enabling C# to run as a container, there's no unified abstraction for file sharing (use of bind mounts is still breaking as k8s publisher crashes)

### Describe the solution you'd like

Introduce a unified abstraction for shared file storage (e.g., `SharedVolume`, `SharedFileStorage`, or similar resource type) that:

1. **Works consistently across deployment scenarios**:
- Local development: handles bind mounts and/or volume mounting between containers
- Kubernetes: translates to PersistentVolumeClaims
- Other deployment targets: adapts appropriately

2. **Enables simple service-to-service file sharing**:
```csharp
var sharedStorage = builder.AddSharedVolume("app-data");
builder.AddContainer("service1").WithVolume(sharedStorage);
builder.AddContainer("service2").WithVolume(sharedStorage);
```

3. **Abstracts away deployment-specific details**: Developers write code once and it works across local Docker, Kubernetes, and other targets without configuration changes.

4. **Works regardless of whether services are containers or directly-hosted**: Whether a service is a .NET app running on the host, a C# container, or any other type of service, they can all reference the shared volume.

### Additional context

**Real-world scenario**:
A C# application running locally through Aspire shares files with a containerized service. Currently:
- Locally: host path is bind-mounted to the container, and C# app references the path directly (since it runs on the host)
- In production: both run as containers with a PVC shared between them

ProjectResourceV2 will help by allowing C# to run as a container, but it doesn't solve the broader abstraction problem. File sharing still requires manual configuration changes between deployment targets.

This feature would enable true "write once, deploy anywhere" semantics for file sharing scenarios.

Start by tracing the existing bind-mount and volume handling for local development, then compare it with the Kubernetes publisher's PersistentVolumeClaim path. Done means a shared-storage resource can be referenced by host-running and containerized services while adapting consistently across local Docker and Kubernetes deployments.

Written by the indexing model from the issue text.