A2A configuration has no runtime effect in `jarvis serve`: clarify library-only versus mounted protocol support

Problem

While following up on the focused-issue guidance in #298, I found that A2AConfig.enabled is part of the loaded configuration, but toggling it does not change the FastAPI surface created by jarvis serve.

This is not a claim that OpenJarvis must expose A2A over the network. PR #416 explicitly described the authenticated A2AServer as defense in depth because the library was not mounted at that time. I am asking which contract is intended before proposing code.

Reproduction

At 759bfd0b98e9f0d391aa8482ca7b3c7dbd5bceea, I created the real app with a deterministic mock engine and sent ASGI requests with a2a.enabled=false, then true.

Probe	disabled	enabled
/.well-known/agent.json	404	404
/a2a/tasks	404	404
/.well-known/agent-card.json	404	404
/message:send	404	404
/tasks/{id}	404	404
/tasks/{id}:cancel	404	404

Both apps exposed 67 routes and no A2A route. Direct calls to A2AServer.handle_request did pass send/get/cancel and bearer-auth tests. The result is therefore a configuration/runtime wiring gap, not a failure of the existing library tests.

The probe was reproduced twice on Windows/Python 3.13.7. Four laboratory tests and the relevant OpenJarvis suites passed (241 passed, 4 skipped).

Protocol boundary

I did not mount the existing route declarations because the current official A2A contract differs from the local historical surface: the public discovery path is /.well-known/agent-card.json, HTTP+JSON uses /message:send and task resource routes, and requests participate in A2A-Version negotiation. The official Python v1.0 migration also changes the data model and offers direct Starlette/FastAPI integration.

I have not run the A2A TCK as a conformance claim because OpenJarvis currently does not advertise a mounted version/transport. That result is marked NOT_APPLICABLE, not pass or fail.

Relationship to existing work

• #298 asked that any remaining bridge become a focused issue with an executable acceptance test.
• #416 secured the library in anticipation of a possible future mount.
• #474 discusses a broader coordination substrate; this issue does not propose Mycelium, shared memory, or distributed coordination.
• #438 already completed the independent Windows installation/service work.

Maintainer question

Should A2A remain a library-only capability, in which case a2a.enabled should be clarified/deprecated, or should it activate a mounted protocol surface in jarvis serve, in which case which A2A version and transport should be the supported contract?

I will not open a PR until that boundary is clear. I can provide the complete probe and machine-readable results if useful.

Disclosure: I used Codex to assist with repository analysis, test execution, and drafting; I reviewed the reproduction and conclusions before posting.