aspire update should not add nuget.org/channel feeds when a custom (mirrored) nuget.config already exists

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

`aspire update` currently assumes every project should end up with the "known channel" NuGet feeds (e.g. `api.nuget.org`, the dnceng `dotnetN` feed, etc.) configured in `nuget.config`, and will offer to add them even when the project intentionally uses its own internal/mirrored feed(s) and nothing else.

This breaks first-party and enterprise scenarios that rely on feed mirroring (e.g. HashR-based repo clones), where `nuget.config` is deliberately scoped to a single internal feed. Running `aspire update` on such a repo offers to add `https://api.nuget.org/v3/index.json` (and a `*` wildcard package source mapping) back in, even though nuget.org was never present and the only configured feed is the internal mirror.

### Expected Behavior

Discussed in the linked Teams thread, the agreed-upon direction is:

1. Before making any changes, run `dotnet nuget list source` (or equivalent) and check whether any of the "known channel" feeds (including `api.nuget.org`) are already present in `nuget.config`.
2. If none of the known channel feeds are present, but the config is **not** empty (i.e. other feed(s) already exist), treat this as a "channel-less" / custom-feed scenario:
- Do **not** add `api.nuget.org`, the channel feed, or any wildcard package source mapping.
- Leave the user's `nuget.config` untouched and rely on whatever feeds/mappings they've already configured to resolve the Aspire packages.
3. Only fall back to the current "add known channel feeds" behavior when `nuget.config` has no feeds configured at all (the genuine zero-feed/new-project case).

In short: the concept of "channels" should be considered incompatible with an existing custom `nuget.config`; if the user already has one, `aspire update` should not try to reconcile it with channel feeds at all.

### Steps To Reproduce

1. Clone a repo that uses NuGet feed mirroring, with `nuget.config` scoped to a single internal feed (no `api.nuget.org`, no dnceng feeds).
2. Run `aspire update`.
3. Observe that the CLI offers to add `https://api.nuget.org/v3/index.json` (and a `*` package source mapping) even though it was never present, alongside the existing internal feed.

### Exceptions (if any)

_No response_

### Aspire doctor output

_No response_

### Anything else?

Related discussion happened in a Microsoft Teams thread between Damian Edwards, Mitch Denny, David Fowler, and Jose Perez Rodriguez. Related issues:

- #19192 — `aspire update` should never override existing wildcard package source mapping (same root cause: re-adding nuget.org/wildcard mapping unconditionally)
- #16946 — nuget.config breaks NuGet packages from private repositories (same root cause: CLI-generated `nuget.config` overrides private/internal feed resolution)
- #17629 — Staging TypeScript AppHost integration restore adds DARC feed without package source mappings (related: unconditional feed addition during restore)

_Created from a [Microsoft Teams conversation](https://teams.microsoft.com/l/message/19%3AuuDJgMCR7JeFSM-0RK2xRW5mAq2WFNfUK0TLmYDvAU01%40thread.tacv2/1787869547872?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=f2e0b0b6-f130-46fa-8ec6-2ef4a7168ed2&parentMessageId=1787869547872)._

Start at the `aspire update` command and the code that inspects or modifies `nuget.config`; reproduce the issue with a config containing only a custom internal feed. Done means existing custom feeds and mappings remain untouched, while known channel feeds are added only when no feeds are configured.

Written by the indexing model from the issue text.