feature: Core Arbitration for Overlapping Plugin Responsibilities in Kagenti AuthBridge

Feature Description

Add Core‑level arbitration logic to Kagenti AuthBridge so that when multiple plugins define behaviors for the same outbound route or token‑handling operation, only one plugin is selected according to a deterministic rule, preventing conflicting actions.

Kagenti AuthBridge supports a plugin architecture - some of the plugins may offer conflicting behavior resulting in failures:

• e.g. when both exchange and broker decide to replace a token

Introduce Core‑level arbitration so that:

• Only one plugin is selected to handle a given outbound request when multiple plugins match and divide the space between them.
• Arbitration happens before plugin execution, not during or after.
• The arbitration mechanism is configurable, predictable, and transparent.

Proposed Solution

Plugins will define what their responsibility ( a string) - e.g. both exchange and broker define a responsibility of "Token Handler". Create a Passthrough plugin - also defined as "Token Handler"

Option 1: Simplify - Remove support for default behavior - Token Handler plugins will only act when they have a defined route. The order of plugins will determine the precedence - the second Token Handler plugin defined will only be called if the first Token Handler plugin do not have a route, etc. If none of the Token Handler plugins have a route - block the route.

Option 2: Move the config of routes to core - core will handle a AuthBridge wide default for all Token Handler plugins. Route has a mandatory host and action - use the Token Handler plugin based on action. Routes may include additional parameters not handled by core and can be used to extend config of the plugins.

Want to contribute?

• I would like to work on this issue.

Additional Context

No response

No files or tests are named. Start by reading the AuthBridge core plugin dispatch, responsibility definitions, and route configuration, then resolve whether Option 1 or Option 2 is intended. Done means a documented, configurable arbitration rule selects one matching plugin before execution and verifies conflicting token-handler cases.