Local hive channel does not surface its packages directory as a NuGet --source during restore

## Summary

When the CLI resolves the `local` channel (or any PR/local hive channel created in `PackagingService.cs:42-61`), the channel correctly maps `Aspire*` packages to the hive's `packages/` directory in code, but `BundleNuGetService` invokes `nuget restore` without that path as a `--source`. Restore then falls through to the public feeds and picks up whichever public preview happens to satisfy the version constraint, completely bypassing the locally built nupkgs.

## Repro

1. Build the repo: `./build.sh --pack /p:SkipNativeBuild=true` (produces `Aspire.Hosting.JavaScript.13.4.0-dev.nupkg` etc. in artifacts/packages).
2. Stage them into a hive directory: `/.aspire/hives/local/packages/*.nupkg`.
3. Use the `aspire-managed` from the same build, with `aspire.config.json` pinning `channel: "local"` and `Aspire.Hosting.JavaScript: 13.4.0-dev`.
4. Run `aspire restore --debug` from a TypeScript apphost.

## Observed

```
[dbug] PrebuiltAppHostServer: Resolved channel: local
[dbug] BundleNuGetService: NuGet restore args: nuget restore ... \
--package Aspire.Hosting.JavaScript,13.4.0-dev ... \
--source https://api.nuget.org/v3/index.json \
--source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json
```

The local hive directory is never passed as a `--source`. NuGet then reaches out to the public feeds and resolves `13.4.0-preview.1.26229.5` (because `13.4.0-dev` < `13.4.0-preview.*` and `--package X,Y` means "min version Y"). The extracted DLLs come from the wrong build, so any new APIs in the local hive (e.g. `WithWorkspaceRoot`) are silently absent from the generated TypeScript SDK / loaded assemblies.

## Expected

The resolved channel's `PackageMapping` set should be reflected verbatim in the `nuget restore --source` arguments. For `local`/PR hives, that means including the on-disk `/packages` path. With it, restore correctly resolves `13.4.0-dev` from the hive (verified by adding a `NuGet.config` containing `` as a workaround — restore then pulls `Aspire.Hosting.JavaScript/13.4.0-dev` and codegen produces the expected `withWorkspaceRoot` binding).

## Workaround

Drop a `NuGet.config` in the apphost directory (or any ancestor) that adds the hive packages path as a feed:

```xml

```

## Impact

- Inner-loop dogfooding of CLI changes is broken: even with a freshly packed local hive, restore silently pulls the public preview, masking any newly added APIs.
- PR-build channels likely have the same issue: the `prHive.Name` channel is created with a packages mapping, but if `BundleNuGetService` doesn't propagate that mapping into the restore command, PR validation runs against whatever is on the public feeds.

## Pointers

- `src/Aspire.Cli/Packaging/PackagingService.cs:42-61` — channel mapping construction
- `src/Aspire.Cli/Projects/PrebuiltAppHostServer.cs` — channel resolution & restore wiring
- `BundleNuGetService` — emits the actual `nuget restore` command with `--source` args (this is where the mappings need to land)