.NET: Split A2A endpoint mapping into protocol-specific methods

[SergeyMenshykh]

Summary

Split MapA2A into protocol-specific methods (MapA2AHttpJson, MapA2AJsonRpc) that are more extensible than extending the A2AProtocolBinding flags enum. This allows exposing the same A2A server with different protocols under different paths if necessary, which was impossible with the previous solution.

Changes

• Rename A2AHostingOptions → A2AServerRegistrationOptions
• Add A2AServerServiceCollectionExtensions to separate DI registration from endpoint mapping
• Remove A2AProtocolBinding enum and AIAgentExtensions (consolidated into the new extensions)

[github-actions]

Automated Code Review

Reviewers: 3 | Confidence: 91%

✓ Security Reliability

This PR cleanly refactors A2A server lifecycle from inline creation during endpoint mapping into proper DI registration via AddA2AServer, with separate MapA2AHttpJson/MapA2AJsonRpc endpoint methods. All public entry points have comprehensive input validation (endpoints, agentName, path). The CreateA2AServer factory is properly scoped as a keyed singleton. No injection risks, secrets, resource leaks, or unhandled failure modes were found. The error message when AddA2AServer is forgotten is clear and actionable. External A2A SDK types (A2AServer, ChannelEventNotifier, InMemoryTaskStore) could not be verified for IDisposable, but since they are registered as DI singletons, any disposable semantics would be handled by the container at shutdown.

✓ Test Coverage

This PR cleanly separates A2A server registration (AddA2AServer) from endpoint mapping (MapA2AHttpJson/MapA2AJsonRpc). The existing A2AgentHandler tests were properly refactored to use the new CreateHandler helper. However, there are several test coverage gaps: the AddA2AServer(IServiceCollection, AIAgent, ...) overload has zero test coverage despite having distinct validation logic, the MapA2AJsonRpc overloads lack argument-validation tests that exist for their MapA2AHttpJson counterparts, the AIAgent-parameter overloads of both MapA2AHttpJson and MapA2AJsonRpc are untested, and the old test verifying the configureOptions callback is actually invoked was removed without replacement.

✗ Design Approach

The refactor improves separation between server registration and transport mapping, but it over-corrects by collapsing all A2A hosting into a keyed-DI A2AServer lookup model. That changes the semantics of the public AIAgent-based API in a way that is broader than a cleanup: callers that already have an AIAgent instance, or that need endpoint-specific behavior, lose direct composition and are now forced through prior DI registration keyed only by agent name. I found one blocking design issue around that regression; otherwise the rest of the change is internally consistent.

Suggestions

• Add argument-validation tests for MapA2AJsonRpc that mirror the existing MapA2AHttpJson tests. Currently only null-endpoints is tested for JsonRpc; missing coverage for null agentName, empty agentName, null path, whitespace path, and null agentBuilder.
• If the goal is to reuse a single A2AServer across transports, keep the AddA2AServer + name/builder-based mapping as an opt-in DI path, but retain AIAgent overloads that build from the supplied instance so the public API still supports non-DI and already-materialized agents.

---

Automated review by SergeyMenshykh's agents