Expose a project resource child PID or evaluated AssemblyName for debugger attach

## Description

The VS Code attach-to-resource action in #18602 currently has to guess the child process name from the raw project file.

The resource properties available over the CLI/backchannel are:

- `executable.path` = `dotnet`
- `executable.pid` = the `dotnet run` launcher, not the user application child
- `executable.args` = redacted
- `project.path` / `project.launchProfile`

That is not enough to identify the process when `AssemblyName` comes from normal MSBuild evaluation outside the project file.

For example:

```xml

My Attach Service

```

With no `AssemblyName` element in the `.csproj`, the running process is `My Attach Service`, but reading the raw project falls back to the project filename. A CoreCLR attach by that fallback name targets a process that does not exist.

## Proposed direction

Could the CLI/DCP backchannel expose either:

1. the actual launched child PID (preferred), or
2. the evaluated `AssemblyName` / process name

as a known project resource property?

The child PID is more reliable because process names can collide and MSBuild properties can change by target framework/configuration. Once available, the VS Code extension can stop parsing project XML and attach directly to the process Aspire launched.

Related: #18602

Start by reading the VS Code attach-to-resource action described in #18602 and the CLI/DCP backchannel resource properties listed here. Done means a known project resource property exposes the launched child PID or evaluated AssemblyName, allowing the extension to attach directly to the process Aspire launched.

Written by the indexing model from the issue text.