Option to restrict a channel to a specific package (do not use it for dependencies)

### Checklist

- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate

### What is the idea?

Currently, when Conda installs a package, if that package is found in a channel, the solver also considers that channel for all dependency resolution.
The idea is to allow restricting a channel so that it can be used only for the explicitly requested package, and not for its dependencies.

Desired state: A user can specify a channel for a package (e.g., -c testing), but Conda will continue resolving dependencies only from other configured channels (such as defaults or conda-forge) unless explicitly instructed otherwise.

### Why is this needed?

This would benefit developers and teams who:
• Maintain testing or experimental channels.
• Want to try a package from such a channel without pulling in unstable or unintended dependencies.
• Need strict reproducibility and isolation in multi-channel workflows.

It solves the current problem where uploading one package to a custom channel exposes all other packages in that channel to the solver, leading to potential conflicts or unwanted dependency versions.

### What should happen?

From a user perspective:

```
# Existing behavior today
conda install conda-forge::mypkg
# → mypkg is taken from conda-forge, dependencies may also be pulled from conda-forge

# Proposed new behavior
conda install testing:::mypkg
# → mypkg is taken from testing channel
# → dependencies are resolved only from defaults/conda-forge (unless explicitly specified)
```

- If a dependency exists only in the restricted channel, Conda should fail with a clear error message and instruct the user how to proceed (e.g., use testing::depX explicitly or allow the channel).

- Multiple restricted packages could be combined:
`conda install testing:::pkgA staging:::pkgB`
Neither channel would be used for other dependencies.

Possible implementation approaches:
• New channel:::pkg spec syntax (extension of the current channel::pkg format).
• CLI flag: --channel-package-only testing.
• Config option in .condarc (e.g., channel_restrictions: { testing: package-only }).

### Additional Context

- Current workarounds (dedicated channel per package, manual pinning in meta.yaml) are inefficient and hard to maintain.
- channel_priority: strict and --override-channels don’t cover this use case, since dependencies are still pulled from the channel.
- The proposed syntax is backward-compatible, ergonomic, and aligns with existing channel::pkg semantics.
- This feature would significantly improve reproducibility and control in environments where experimental or internal channels coexist with stable channels.