Store polyglot AppHost restore artifacts under the workspace instead of ~/.aspire/packages/restore

[IEvangelist]

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

The CLI's polyglot restore path currently writes restore outputs to a global user-profile cache under ~/.aspire/packages/restore/{hash}. These restore outputs are effectively workspace/AppHost-scoped operational artifacts (obj plus flattened libs layout), but they accumulate in a shared global location that is hard to attribute back to the consuming project.

On one Windows machine, while investigating this behavior:

• ~/.aspire was about 23 GB
• ~/.aspire/packages/restore was about 22.24 GiB of that total
• there were 405 hashed restore directories
• most of the size was repeated library payload across many restore buckets rather than a few large files

This makes disk usage surprising, especially for users working across many polyglot AppHosts or staging builds. Even though aspire cache clear exists, it is a blunt global cleanup command; it does not make it easy to understand which workspace produced which restore outputs or to clean up one workspace without affecting others.

Related issues:

• Polyglot (guest) AppHost restore does not isolate staging NuGet packages from global cache #15399 tracks staging/feed isolation and cache-key collisions in this same restore path
• Polyglot AppHost doesn't respect $env:NUGET_PACKAGES #15404 tracked NUGET_PACKAGES not being respected

This issue is about the broader location / ownership / lifecycle of polyglot restore artifacts.

Describe the solution you'd like

Prefer storing polyglot restore outputs under the consuming workspace, for example under ./artifacts/aspire/restore/... (or a similar workspace-local path), instead of under ~/.aspire/packages/restore.

That would make these artifacts:

• easier to attribute to the project that created them
• easier to clean up with normal workspace cleanup flows
• easier to ignore from source control
• less surprising from a disk-usage perspective

A few possible designs:

1. Default to a workspace-local restore/artifacts directory for polyglot AppHost restore outputs
2. Keep a shared global package-download cache if needed for performance, but materialize extracted obj / libs layouts locally
3. Offer a config/CLI switch to opt into global vs workspace-local behavior
4. If the global location remains, add metadata and pruning so old restore buckets can be understood and cleaned up more surgically

Additional context

Relevant code paths:

• PrebuiltAppHostServer.RestoreNuGetPackagesAsync() routes polyglot package restore through BundleNuGetService
• BundleNuGetService.GetCacheDirectory() hardcodes ~/.aspire/packages
• BundleNuGetService.RestorePackagesAsync() writes restore/{hash}/obj and restore/{hash}/libs
• BundleNuGetService.ComputePackageHash() currently keys the restore bucket on package IDs/versions + TFM

One nuance: these restore directories are not strictly "per AppHost"; they are keyed by the restore inputs, which in practice often means one bucket per distinct polyglot AppHost/integration set.