WIP: feat: expose server notifications as an effect-specific stream

[sideeffffect]

Closes #222.

What

Alongside the existing callback API (onServerNotification), each streaming client module now exposes server-pushed notifications as a stream native to its effect backend, via a serverNotifications extension on BidirectionalMcpClient:

Module	Type
chimp-client-ox	ox.flow.Flow[ServerNotification]
chimp-client-zio	ZStream[Any, Throwable, ServerNotification]
chimp-client-pekko	Source[ServerNotification, NotUsed]

Each stream registers a listener when it is run/materialized and removes it when it finishes, so it does not leak listeners for the lifetime of the client.

import chimp.client.transport.zio.*

val notifications: ZStream[Any, Throwable, ServerNotification] = client.serverNotifications

How

• BidirectionalMcpClient gains removeServerNotification(listener) (listeners compared by reference) so the streams can release their listener on completion. This is the only change to the public core API; the only implementor of the trait is the internal client impl.
• ox uses an unbounded channel and zio an unbounded queue, so delivery never blocks the transport read loop; pekko uses a BoundedSourceQueue (synchronous, order-preserving FIFO) that drops the newest notification when the buffer is full.

Tests

• Core: CapabilityHandlerSpec gets a case asserting removeServerNotification stops delivery.
• One spec per backend ({Ox,Zio,Pekko}ServerNotificationsSpec) driving a shared FakeNotificationClient, asserting the stream emits pushed notifications in order and removes its listener when done.
• sbt scalafmtCheckAll compile Test/compile compileDocs and the affected unit suites pass locally.

Notes

• Buffering/overflow semantics differ slightly per backend to fit each concurrency model; documented in the scaladoc and docs/client/capabilities.md.
• Marked as a draft/WIP.

🤖 Generated with Claude Code