feat(runtime): live A2A JSON-RPC listener via ca2a start

[Susanpdl]

Summary

• Adds ca2a start and ca2a_runtime.server: Starlette JSON-RPC listener for message/send that runs parse_peer_request → handle_peer_request end to end (verify chain, intersect local/Cedar policy, open sealed payload when a key is configured, emit provenance).
• Ordinary A2A (no cA2A keys) returns ca2a: null without inventing a trust state; malformed metadata and denials fail closed with data.ca2a_code.
• Config gains local_policy and optional enclave_private_key_hex; install with pip install 'ca2a-runtime[serve]'.

Closes the second Tier 2 checkbox on #47 (live inbound wiring). Does not claim attestation handshake or seal-to-verified-measurement binding.

Test plan

• ruff check src/ tests/
• mypy src/ca2a_runtime/ src/ca2a_verify/
• pytest tests/unit/ tests/conformance/ (195 passed)
• CI green on this PR
• Manual: ca2a start --config examples/minimal/ca2a-config.yaml then POST a message/send envelope to /rpc

[imran-siddique]

Reviewed the diff and thread. Scope is tight and matches the body: live inbound A2A JSON-RPC wiring for the second Tier 2 checkbox, with ordinary A2A returning ca2a: null rather than inventing a trust state, and malformed metadata plus denials failing closed with a structured ca2a_code. X25519 key handling validates length and is software-configured only, with the docs correctly caveating that it is not measurement-bound. No secrets in the diff; test keys are generated at runtime. Tests cover config, policy loader, and server paths, and all real checks are green. LGTM. Leaving the merge to a maintainer.

[imran-siddique]

@Susanpdl this is approved and ready except for a merge conflict with main. Could you merge main into feat/live-a2a-inbound-serving (or rebase) and resolve the conflict? Once it is clean it can go in. Thanks.

[Susanpdl]

Happy to resolve the conflict, but I want to check the shape with you first, because #53 landed after your approval here and it overlaps with this branch.

The conflict itself is small: CHANGELOG.md, LIMITATIONS.md, ROADMAP.md, docs/spec/transport.md, and pyproject.toml. No code conflicts.

The bigger question is duplication. #53 added transport/server.py, node.py, and the attestation handshake, so there is already a live HTTP serving path on main. This branch adds a second one (ca2a_runtime/server.py, a Starlette JSON-RPC listener for message/send), and it pulls in starlette and uvicorn, which cuts against the standard-library-only choice you made in #53.

What is still missing on main and is the part of this PR I think is worth keeping:

• ca2a start. The CLI only has validate-config, verify-chain, and verify-dag, so there is no command to actually run a peer.
• Config-driven policy: local_policy plus loading Cedar from policy_bundle_path, and listen_addr actually being consumed.
• An optional configured enclave key for opening a sealed payload.

So my suggestion is to refit this branch instead of merging it as-is: keep ca2a start and the config/policy loading, but have it build a PeerNode and serve through transport.server.serve(), then drop my server.py and the [serve] extra. That removes the duplicate server, adds no new dependencies, and the CLI path inherits your handshake rather than using a raw configured key.

Want me to go that way, or would you rather keep the two transports separate (JSON-RPC alongside the reference server), or just close this and open a smaller CLI-only PR? Happy to do whichever you prefer.