Add provider-trait gating for rule types (`provider_traits`)

[intelligent-ears]

Problem

Rule types have no declared, up-front way to say "I require an implementation of API Y." Today, provider-specific scoping either:

• doesn't exist (rule type just assumes a shape and may fail/behave oddly against a provider that doesn't implement the API it needs), or
• gets pushed into CEL profile selectors, which evaluate per-entity and return ErrEvaluationSkipped on mismatch. This isn't silent — it shows up in evaluation status/history — but it does mean every non-matching entity generates skip noise instead of the rule type simply not applying.

This is currently blocking osps-ac-03-02 (branch deletion protection), since GitHub and GitLab branch-protection semantics/APIs differ enough that a single generic rule type can't cleanly cover both.

Framing (important distinction)

The field declares "this rule type requires API Y," not "this rule type is for provider class X." In some cases (git, OCI) API Y is standardized and multiple providers can implement it. In other cases the API is specific to a single company/provider class (GitHub management API, Docker management API, various cloud provider APIs) — that looks like "this rule is for provider class X," but it's really "only this provider
currently implements API Y." The distinction matters for how the field should be understood and extended as more providers implement overlapping APIs.

Proposed direction

Add a provider_traits field to the rule type schema, checked by rtengine before evaluation — the same way entity-type gating already works today — rather than relying on profile selectors. This reuses the existing ProviderType/CanImplement trait vocabulary (pkg/providers/v1/providers.go), so a rule type declares which trait(s) it needs (e.g. github-api, git, oci), not a specific named provider registration — a single rule type can apply across multiple provider instances that implement the same trait.

Sub-issues

• Schema: add provider_traits field to rule type proto/schema
• Engine: rtengine check for provider_traits before eval
• Apply provider_traits to unblock osps-ac-03-02
• Docs: document provider_traits for rule type authors

Context

Design discussed with @evankanderson — reusing the existing ProviderType/CanImplement trait pattern rather than introducing a new capability abstraction, since GitHub/GitLab branch protection differ enough in shape that a boolean "supports X" capability flag would hide more than it clarifies. Naming settled on provider_traits over required_traits since the latter doesn't make clear who/what is doing the requiring (rule type vs. entity vs. policy). Open to a better name before this ships if one comes up.

[evankanderson]

Slight clarification:

We want a way for a ruletype to declare "I operate against API Y". In some cases (git, OCI), that API may be standardized, but there are a lot of cases where the API happens to be specific to a single company/provider class (GitHub management API, Docker management API, various clouds, etc).

The second case looks a lot like "rule is for this provider class", but it's actually "only this provider implements API Y".

[evankanderson]

I'm also not a fan of the specific name required_types in a ruletype context. Neither word provides a lot of information on its own -- something like "provider traits" would be better (though we've called the traits "types" in the existing provider API because names are hard and we didn't do a great job there).

[intelligent-ears]

Good distinction, and it clarifies something I was fuzzy on. Restating to make sure I've got it: the field declares "this rule type requires an implementation of API Y," not "this rule type is for provider class X." For standardized APIs (git, OCI) multiple providers can satisfy that. For company-specific APIs (GitHub management API, etc.) it just happens that today only one provider implements Y — but that's incidental, not the thing being declared.

On naming: agree required_types doesn't carry much meaning on its own. Since the existing provider API already uses "trait" informally for this concept (CanImplement(trait ProviderType)), what about required_traits (or provider_traits) for the rule type field? Keeps it consistent with the existing vocabulary rather than introducing a third term.

Will update the schema sub-issue with this framing + naming if that works for you.

[evankanderson]

Of the two, I'd prefer provider_traits for a field in the ruletype. required_traits is not particularly clear who or what is doing the requiring (does the ruletype need the traits? the entity? the policy?).

I'm still open to a better name if we think of one before the API has been exposed/used -- names are important to give API users clues on how to use the API.

[intelligent-ears]

Good point on required_traits being ambiguous about the subject — provider_traits is clearer, agreed. Will go with that for now and update the schema sub-issue accordingly. If a better name comes up before this ships I'm happy to revisit, but this seems solid to build against.