fix(a2a): declare a2a-sdk[http-server] so the a2a extra can serve

[arunpshankar]

Link to Issue or Description of Change

No existing issue.

Problem:

The a2a extra installs a2a-sdk with no extras. That is enough to
import the package but not to run the server: sse-starlette is declared
only under a2a-sdk's http-server, fastapi and all extras, and every
server dispatcher imports it at module level.

to_a2a() builds an A2AStarletteApplication, which routes through
a2a.server.routes.jsonrpc_dispatcher, so a clean install of
google-adk[a2a] fails at startup with:

ModuleNotFoundError: No module named 'sse_starlette'

This stays invisible during development because mcp requires
sse-starlette, so any environment that has ever installed the mcp extra
already satisfies it by accident. It surfaces on the first genuinely
clean install — typically a container — and the runtime then reports a
failed startup probe on the port rather than the missing module, which
sends you looking at networking instead of packaging.

Solution:

Declare a2a-sdk[http-server] in the a2a extra.

http-server rather than a direct sse-starlette pin because it states
the intent — ADK serves the A2A HTTP application — and leaves the
transitive set to a2a-sdk to decide. The extra exists at the pinned floor
(0.3.4) and carries sse-starlette through the current 1.1.2, so it holds
across the whole >=0.3.4,<2 range.

This is not the lazy-import case that some earlier dependency reports
turned out to be: the import lives inside a2a-sdk rather than in ADK, and
it is needed to serve, not merely to import.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally (unaffected by this change).

No unit test is added, and I want to be explicit about why rather than
add a token one: this is an install-time property, and CI installs the
extras it needs, so the failure is not observable from inside a test
session that can already import the module. Happy to add one if you would
like it — the natural home looks like the packaging-adjacent checks in
tests/unittests/test_import_loading.py.

That file's test_constructing_agent_defers_optional_mcp_server_stack
asserts sse_starlette is not imported when constructing an Agent.
This change does not affect it: installing a package does not import it.

Manual End-to-End (E2E) Tests:

From an empty virtualenv, installing exactly what the a2a extra
installs today:

$ pip install "a2a-sdk>=0.3.4,<2"
$ python -c "import a2a.server.routes.jsonrpc_dispatcher"
ModuleNotFoundError: No module named 'sse_starlette'
$ python -c "import a2a.compat.v0_3.jsonrpc_adapter"
ModuleNotFoundError: No module named 'sse_starlette'
$ python -c "import a2a.server.routes.rest_dispatcher"
ModuleNotFoundError: No module named 'sse_starlette'

With this change:

$ pip install "a2a-sdk[http-server]>=0.3.4,<2"
$ python -c "import a2a.server.routes.jsonrpc_dispatcher"   # ok
$ python -c "import a2a.compat.v0_3.jsonrpc_adapter"        # ok
$ python -c "import a2a.server.routes.rest_dispatcher"      # ok

pyproject-fmt==2.24.0, the version pinned in .pre-commit-config.yaml,
reports no change for pyproject.toml.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• My changes generate no new warnings.

[arunpshankar]

Stronger repro than the one in the description — this is the released
package rather than a2a-sdk in isolation.

Clean venv, pip install "google-adk[a2a]" and nothing else:

google-adk           2.6.3
a2a-sdk              1.1.2
sse-starlette        not installed

from google.adk.agents.llm_agent import LlmAgent
from google.adk.a2a.utils.agent_to_a2a import to_a2a

agent = LlmAgent(name="policy_agent", model="gemini-2.5-flash",
                 description="d", instruction="i")
app = to_a2a(agent)                      # returns a Starlette app fine

async def boot():
    async with app.router.lifespan_context(app):
        ...
asyncio.run(boot())

to_a2a() returned an app: Starlette
ModuleNotFoundError: No module named 'sse_starlette'

Two details that make this worse than a plain missing dependency:

to_a2a() succeeds. The failure lands in the Starlette lifespan, at
startup, because that is where the A2A routes are attached — so nothing
is wrong until the process tries to serve. Under a container runtime the
surfaced error is a failed startup probe on the port, not the missing
module, which points debugging at networking instead of packaging.

And it does not reproduce on most development machines, because mcp
requires sse-starlette: any environment that has ever installed the mcp
extra already satisfies it by accident. It shows up on the first clean
install, which is usually the first deploy.