rtengine: gate rule evaluation on `provider_traits`

[intelligent-ears]

Before evaluating a rule type against an entity, rtengine should check whether the entity's provider implements the trait(s) listed in the rule type's provider_traits (if set), the same way it already gates on entity type. If the provider doesn't implement the required trait, the rule type should not run against that entity — analogous to how entity-type mismatches are handled today, not via ErrEvaluationSkipped.

Depends on: schema field from sub-issue 1.

[intelligent-ears]

Looked into where this would plug in before writing any code. Proposed design:

pkg/engine/v1/interfaces/provider.go defines a narrow Provider interface that rtengine actually receives — currently empty (type Provider interface {}), with a comment noting it's a slice of the full pkg/providers/v1.Provider interface containing "only the methods needed for engine evaluation (currently none)". That's the natural extension point: add

type Provider interface {
    CanImplement(trait minderv1.ProviderType) bool
}

Every concrete provider (github, gitlab, oci, dockerhub, ghcr, noop, testproviders, testkit) already implements CanImplement with this exact signature, so widening the interface shouldn't require touching any provider implementation.

Then in pkg/engine/v1/rtengine/engine.go, NewRuleTypeEngine already receives both provider interfaces.Provider and ruletype *minderv1.RuleType up front, before constructing the ingester/evaluator — right where the existing ruletype.Context.GetProject() == "" check lives. Adding a loop over ruletype.GetDef().GetProviderTraits() calling provider.CanImplement(trait) there gives the same "reject at construction time" behavior as that existing check, rather than a runtime ErrEvaluationSkipped.

This felt like the cleanest fit given the existing shape of the code, but wanted to check before writing it up. Should i proceed with this @evankanderson

[evankanderson]

That plan makes sense to me.