Support operation-aware resolution of plugin-provided credentials

[saltbo]

Problem

Credential selection can depend on the effective OpenAPI security requirements of the target operation, including required scopes and alternative security schemes.

A plugin that receives only the final HTTP request cannot select a credential safely from the URL alone. Requiring plugins to repeat OpenAPI route matching and security inheritance would duplicate Restish behavior and can produce a credential that does not cover the operation.

Required behavior

• resolve effective security requirements for generated operations
• resolve the same metadata for generic API-relative requests when method and path identify one operation
• preserve OpenAPI OR/AND security semantics, document-level inheritance, operation-level overrides, and explicit security: []
• allow a credential resolver to claim a supported security alternative or decline
• retain configured credentials as the explicit priority
• fail when multiple resolvers claim the same unresolved requirement
• omit inferred operation metadata for unresolved, ambiguous, or raw requests
• acquire provider-backed credentials through an explicit credential-source boundary rather than per-request header injection

Compatibility and security

• new resolver and credential-source hooks are optional
• existing plugins continue to operate unchanged
• resolvers do not receive credential secrets or private keys
• credential sources receive only the bounded acquisition input needed for the selected operation
• inspection can represent deferred resolution without invoking providers or exposing secrets

Acceptance criteria

• generated and generic matched requests select credentials from effective operation security
• scope coverage is validated before sending a credential
• anonymous operations do not invoke resolvers
• ambiguity and insufficient scope fail closed
• operation inheritance and override behavior are covered by tests