[Kehrlann]

• Transports need to list a context's entries and combine contexts, for instance to add the decoded Mcp-Param-* headers to a context built by a user-provided extractor.
• This introduces a way to merge McpTransportContext. To do so, it introduces a way to read entries from the contexts, by key-value.
• This change is non-breaking but custom implementations of McpTransportContext used in the modern server MUST implement stream().

The implementation is inspired from Reactor's Context.

[chemicL]

#1288 as an alternative solution to the need.

Reasons:

• We don't have to create a generic Context-like implementation here.
• We don't need to iterate at this time as the intended usage is to grab a specific key's value.
• For the most common case we can just merge two maps, we don't need streaming/iterating over the contents.
• In case of user implementations of the McpTransportContext implementation we can provide an overlay instead of iterating, too.

Thus, we can avoid the breaking change and just have a default method with a working implementation.

[Kehrlann]

@chemicL I didn't go with this approach because a user's ContextExtractor could return a custom implementation of McpTransportContext, e.g. MyTransportContext - and user code may rely on this behavior.

Wrapping it all in an "overlay" breaks the user's type.

But reducing to #putAll(Map) and not supporting #putAll(McpTransportContext) simplifies this a lot; avoiding the wrapping is easy enough as there's a single method to implement.

[chemicL]

There is no guarantee that what the user gets in handlers is the same that the extractor returned. I don't think we should protect implementations that assume their specific type to be present. We do adhere to the contract of providing an instance of the interface, that's all.