feat(setup): add optional A2A harness adapter

[satyaborg]

Why

Kensa setup currently has to trace an unfamiliar repository until it finds and proves the production function or class that starts one conversation. In arbitrary codebases, that execution seam is often ambiguous even when the deployed agent has a clear external entry point.

An A2A-compliant target already publishes an Agent Card with supported interfaces, capabilities, skills, input and output modes, and authentication requirements. For those targets, Kensa should be able to use the protocol boundary as the approved production entry point instead of reverse-engineering an internal callable.

References:

• Kensa harness fixture
• Kensa setup workflow
• A2A protocol specification
• A2A Python SDK

Goal

Add an optional A2A setup path that reduces an A2A-backed kensa_run fixture to configuration plus a reusable Kensa adapter, while preserving the existing source-tracing workflow for non-A2A agents.

Proposed behavior

1. Add an optional A2A ConversationAgent adapter constructed from an Agent Card URL.
2. Keep one adapter and one server-issued conversation context per trial.
3. Send the actual A2A message from respond(), not during fixture construction, so Kensa owns timeout and tracing semantics.
4. Preserve opaque contextId and taskId values across simulated turns.
5. Consume streaming or non-streaming responses until a stable task state, then map A2A messages, task status, and artifacts into ConversationResponse.
6. Translate available target trace metadata into AgentRunEvidence; explicitly mark trajectory evidence incomplete when the target exposes none.
7. Teach kensa-setup to prefer an explicitly configured or repository-confirmed Agent Card, present its endpoint, version, skills, auth requirements, environment, and effects for approval, then scaffold the generic fixture.
8. Fall back to the existing source-tracing workflow when no confirmed A2A boundary exists.

A resulting fixture should be approximately:

@pytest.fixture
async def kensa_run(case):
    async with A2AConversationAgent.from_url(
        os.environ["A2A_AGENT_URL"],
        initial_input=case.input,
    ) as agent:
        yield agent

The exact public API is part of the design work.

Acceptance criteria

• Direct and simulated multi-turn cases work through an A2A target.
• Trial isolation prevents sharing contextId or taskId values.
• Agent Card interface and capability negotiation is validated before invocation.
• Authentication remains repository-owned and follows existing credential approval rules.
• Failed, cancelled, rejected, and input-required task states have explicit Kensa mappings.
• Unsupported Kensa message roles or A2A content modes fail with actionable contract errors rather than being silently dropped.
• A2A artifacts remain JSON-serializable in ConversationResponse.output.
• Available external run and trace evidence is attached without claiming completeness that the target did not provide.
• kensa doctor validates an approved A2A fixture without weakening authenticity, side-effect, model-spend, or readiness checks.
• Existing non-A2A harness setup behavior remains unchanged.
• Focused tests cover invocation boundaries, streaming, multi-turn state, error mapping, cleanup, and evidence attachment while preserving the configured coverage gate.
• Documentation explains when the A2A path evaluates a deployed boundary versus local in-process code.

Non-goals

• Converting arbitrary agents into A2A servers.
• Making A2A mandatory for Kensa.
• Treating Agent Card skills as directly invokable code entry points.
• Reconstructing missing prompts, tools, routing, state, or production behavior in the fixture.
• Bypassing approval for credentials, real-model spend, or live side effects.
• Depending on a non-core traceability extension for basic operation.

Open design questions

• Whether the adapter belongs in core or an optional kensa[a2a] extra.
• Whether initial system, developer, and tool messages should be rejected or supported only through an explicit extension.
• How A2A task completion should relate to Kensa conversation termination.
• Which A2A protocol bindings to support initially.
• How to record Agent Card version, target revision, endpoint, and effect attestation reproducibly.