fix(server): normalize experimental capability to {} in get_capabilities

[Hamjaster]

Fixes #3254

What's broken

An unconfigured Server reports its experimental capability differently depending on which discovery path answers:

• initialize (via create_initialization_options()): experimental == {}, field present on the wire.
• server/discover (calls get_capabilities() directly): experimental is None, field omitted from the wire dump.

That's client-visible: .get(...) works on the legacy value and raises on the modern one, and is not None checks flip meaning depending on which path answered. Same server, same lack of configuration, two different answers.

Why

create_initialization_options() was the only caller that normalized a missing experimental_capabilities argument to {} before handing it to get_capabilities(). get_capabilities() itself just used its own parameter default (None) whenever a caller didn't do that normalization first — and server/discover's internal handler calls get_capabilities(protocol_version=ctx.protocol_version) with nothing for experimental_capabilities, so it fell straight through to None.

The fix

One line: move the normalization into get_capabilities() itself, right next to the existing notification_options = notification_options or NotificationOptions() fallback that already does the same job for a sibling parameter. Now every caller gets {} unless it explicitly passes something else, regardless of which path calls it.

How I checked it

Ran the exact repro from the issue against both trees:

# main
legacy {} True
modern None False

# this branch
legacy {} True
modern {} True

Added a test in tests/server/lowlevel/test_server_discover.py (the file that already exercises get_capabilities() via the discover path) asserting both create_initialization_options() and server/discover report experimental == {} for the same unconfigured server. It fails on main with assert None == {} and passes with this change.

ruff format/ruff check/pyright are all clean. Ran the full tests/server/ suite (1213 tests) and it passes. I didn't run the complete coverage/strict-no-cover gate across the whole repo, but confirmed the new line is exercised (not in coverage report's missing-lines list) when running the affected test files.

Type

🐛 Bug Fix

Disclosure

An AI coding agent helped me write this. I read the SDK's fallback pattern in get_capabilities(), picked the one-line fix that matches it, reproduced the issue's exact repro on both trees myself, and can walk through any part of this change.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}