[Feature]: Feed provenance policy asserting which feed a package must come from

### Background and motivation

The configuration supports `allow.feeds` and `ignoredFeeds`, so feeds can be permitted or ignored in general. What cannot be expressed is the stronger and more useful assertion: *this specific package must come from this specific feed*.

That assertion is what protects against a private package being shadowed by a public one. If `Contoso.Internal.Auth` is supposed to come from an Azure Artifacts feed and one day resolves from nuget.org instead, something has gone wrong — whether that is a misconfigured `nuget.config`, a package source mapping mistake, or an actual dependency-confusion attack. Either way it should fail loudly, and today it passes silently.

PackageGuard already records the resolving feed for every package, so the data needed is in hand.

**Proposal**

```json
{
"settings": {
"feedPolicy": {
"Contoso.*": "*pkgs.dev.azure.com/contoso*",
"Microsoft.*": "https://api.nuget.org/v3/index.json",
"*": "any"
}
}
}
```

Any package matching a pattern must resolve from a matching feed, or it is a violation.

Design points:

- **Pattern matching should reuse `PackageSelector`.** The wildcard syntax already used for packages should carry over, so there is one syntax to learn.
- **Precedence.** With overlapping patterns, most-specific-wins is the intuitive rule, and it needs to be documented with examples because it will otherwise be a recurring source of confusion.
- **Feed change detection.** Independently of any configured policy, warning when a package resolves from a different feed than in the previous cached run is a cheap and high-signal check. It requires no configuration at all, which makes it the more likely thing to catch a real incident.
- **Relationship to package source mapping.** NuGet's own package source mapping prevents this problem at resolution time and is the better primary control. PackageGuard's role here is verification: confirming the intended mapping is actually in effect, and reporting when it is not. That is worth stating explicitly in the documentation so the feature is not mistaken for a replacement.
- **Reporting.** A violation should show both the expected and actual feed, since the actual feed is the diagnostic information.
- **npm.** The same concern applies to scoped packages and private registries configured in `.npmrc`, so the design should not be NuGet-specific.

### Alternative Concerns

- NuGet package source mapping addresses the root cause and should be recommended alongside this, but it is per-repository configuration that is easy to get wrong or forget, and nothing currently verifies it.
- The internal-namespace detection proposed in the typosquat/dependency-confusion issue overlaps with this. That issue frames it as heuristic detection; this one frames it as explicit declared policy. They could reasonably be implemented as one mechanism.

### Are you willing help with a pull-request?

No

Start by reading the existing PackageSelector behavior and the code that records each package's resolving feed. Define how feedPolicy configuration, most-specific pattern precedence, feed-change detection, violation reporting, and NuGet/npm behavior fit together; done means the policy and reporting behavior are documented and covered for the stated scenarios.

Written by the indexing model from the issue text.