Stream modern request notifications and honor the envelope logLevel per SEP-2575

## Motivation and Context

The modern (stateless) lifecycle of MCP 2026-07-28 serves each request as a self-contained exchange,
and two delivery requirements of that model were unimplemented:

- Notifications a handler emits while serving a modern request (progress, log messages)
  had nowhere to go: the modern path answered with a single JSON object,
  and the ephemeral per-request session degraded every notification to non-delivery.
  The conformance requirement expects them as frames on the request's own response stream
  (`tools-call-with-progress` fails with "No progress notifications received" at 2026-07-28).
- The envelope's `logLevel` member, which replaces the removed `logging/setLevel` RPC,
  was parsed but never applied: log delivery fell back to the server-wide level, violating the requirement
  that no `notifications/message` is sent for requests that did not set `_meta` `logLevel`.

The changes wire both up:

- `StreamableHTTPTransport#handle_modern` registers a per-request notification sink for its ephemeral session;
  `send_notification` routes into the sink ahead of the stateless guard.
  A request whose handler emitted notifications answers as an SSE stream carrying them ahead of the final response;
  a request that emitted none keeps the single JSON exchange and its HTTP status ladder.
- `Server#handle_request` applies the lifted envelope's `logLevel` to the session via the existing `configure_logging`,
  and on modern-era sessions `ServerSession#notify_log_message` no longer falls back to the server-wide level:
  without a per-request `logLevel` it stays silent, on every transport. An unrecognized level reads as absent,
  the safe direction, matching the Python SDK's `allowed_log_levels`.

The `server-stateless` scenario of the 2026-07-28 conformance requirements probes two stream-discipline
rules through diagnostic fixture tools the Ruby fixture did not define, so both checks failed as
not testable: `sep-2575-http-server-no-independent-requests-on-stream` calls `test_streaming_elicitation`
and requires that every frame on the request's response stream is a notification or the final response,
and `sep-2575-server-no-log-without-loglevel` calls `test_logging_tool` without an envelope `logLevel`
and requires that no `notifications/message` reaches the stream.

The fixture now defines both tools. `test_streaming_elicitation` reports progress and completes;
`test_logging_tool` calls `notify_log_message` unconditionally and relies on the SDK's per-request gate,
which drops the notification for modern requests that did not authorize logging through
`io.modelcontextprotocol/logLevel`. Both lean on the notification streaming this change adds:
with a `progressToken` or an authorizing `logLevel`, the notification is delivered as an SSE frame
ahead of the final response rather than being dropped.

One known limitation relative to the TypeScript and Python SDKs, which stream notifications live while the handler runs:
delivery here is buffered, flushing the frames after the handler returns. Ordering is preserved
and the conformance checks are satisfied, but long-running handlers get no real-time interleaving.
The sink is bounded (`MAX_MODERN_REQUEST_NOTIFICATIONS`, 1000): a handler emitting notifications
in proportion to client-supplied input cannot grow one request's memory without bound,
and past the cap the notify helpers report `false`, the same non-delivery degradation
they have on every other undeliverable path. Live streaming can follow without changing the wire shape.

## How Has This Been Tested?

`bundle exec rake test` passes with zero failures and RuboCop reports no offenses. New tests cover:
a modern `tools/call` streaming `notifications/progress` frames ahead of the result, the single JSON exchange staying
in place without notifications, log suppression without the envelope `logLevel`, log delivery with it,
the modern-era session ignoring the server-wide level while honoring a per-request one,
and the notification cap bounding one request's buffered frames while the notify helpers report `false` past it.

Against the conformance fixture server, the `tools-call-with-progress` progress check passes
at `--spec-version 2026-07-28` (its remaining wire-schema check belongs to the separate `resultType` change),
the stream-discipline checks `sep-2575-http-server-no-independent-requests-on-stream` and
`sep-2575-server-no-log-without-loglevel` report SUCCESS, and manual probes confirm the positive
directions the suite leaves untested: with `io.modelcontextprotocol/logLevel` in `_meta`,
`test_logging_tool` streams its `notifications/message` frame ahead of the result, and
with a `progressToken`, `test_streaming_elicitation` streams its `notifications/progress` frame.
The `--requirements 2025-11-25` server leg passes 78/78, unchanged.

## Breaking Changes

None for stable protocol versions: legacy requests and their notification delivery are unchanged.
Within the modern lifecycle, notifications become deliverable where they were previously dropped,
and log messages without a per-request `logLevel` stop leaking through the server-wide level,
as the specification requires.

conformance/server.rb

@@ -344,6 +344,21 @@ module Conformance
       end
     end
 
+    class TestStreamingElicitation < MCP::Tool
+      tool_name "test_streaming_elicitation"
+      description "A tool whose response stream carries only notifications, never independent requests (SEP-2575)"
+
+      class << self
+        def call(server_context:, **_args)
+          # No independent server-to-client request is ever written to the response stream;
+          # the progress notification only goes out when the request carried a progressToken.
+          server_context.report_progress(50, total: 100)
+
+          MCP::Tool::Response.new([MCP::Content::Text.new("Streaming complete").to_h])
+        end
+      end
+    end
+
     class TestInputRequiredResultElicitation < MCP::Tool
       tool_name "test_input_required_result_elicitation"
       description "A tool that asks for the user's name through an input_required result (SEP-2322)"
@@ -609,6 +624,21 @@ module Conformance
         end
       end
     end
+
+    class TestLoggingTool < MCP::Tool
+      tool_name "test_logging_tool"
+      description "A tool that logs only for requests opting in via the _meta logLevel (SEP-2575)"
+
+      class << self
+        def call(server_context:, **_args)
+          # On modern requests the notification is dropped unless `io.modelcontextprotocol/logLevel` authorized it,
+          # so the call itself is unconditional.
+          server_context.notify_log_message(data: "Log level honored", level: "info", logger: "conformance")
+
+          MCP::Tool::Response.new([MCP::Content::Text.new("Logging evaluated").to_h])
+        end
+      end
+    end
   end
 
   module Prompts
@@ -846,6 +876,8 @@ module Conformance
           Tools::TestInputRequiredResultMultipleInputs,
           Tools::TestInputRequiredResultMultiRound,
           Tools::TestInputRequiredResultCapabilities,
+          Tools::TestStreamingElicitation,
+          Tools::TestLoggingTool,
         ],
         prompts: [
           Prompts::TestSimplePrompt,