server-stateless: `sep-2575-http-server-no-independent-requests-on-stream` probe never declares the elicitation capability its own fixture requires

[logiscapedev]

Describe the bug
The server-stateless scenario builds one shared request _meta envelope with
"io.modelcontextprotocol/clientCapabilities": {} (src/scenarios/server/stateless.ts, validMeta)
and reuses it for every check. The sep-2575-http-server-no-independent-requests-on-stream check
drives its streaming probe by calling tools/call with name: "test_streaming_elicitation" under
that empty-capabilities envelope.

Per SEP-2575, a server MUST reject a request that exercises a capability the client did not declare
with -32021 MissingRequiredClientCapability — the exact behavior the sibling check
sep-2575-server-rejects-undeclared-capability (same scenario, same shared envelope, fixture
test_missing_capability) verifies and rewards two checks earlier. So a spec-correct,
capability-enforcing server necessarily answers the streaming probe with -32021, and the check
can never be exercised against it.

Before #372 this reported SKIPPED; since #372 (alpha.8) it scores a hard failure:

the 'test_streaming_elicitation' call was rejected (code -32021), so the response stream could
not be exercised

The scenario is now internally contradictory: one check requires the -32021 rejection that breaks
the other.

To Reproduce
Steps to reproduce the behavior:

1. Run server-stateless at 0.2.0-alpha.9 against any server that enforces per-request capability
   declaration (observed with the PHP SDK, logiscape/mcp-sdk-php v2 main, whose everything-server
   exposes the test_streaming_elicitation fixture): 27/28 checks pass;
   sep-2575-http-server-no-independent-requests-on-stream fails with the message above. The only
   ways to "pass" today are to strip the capability requirement from the fixture (defeating its
   purpose of demonstrating SEP-2322 elicitation-as-InputRequiredResult) or to stop enforcing
   capability declaration (failing sep-2575-server-rejects-undeclared-capability).

Expected behavior
Declare the capability the probe needs, at the probe site only — the shared validMeta must stay
empty because sep-2575-server-rejects-undeclared-capability depends on it:

_meta: { ...validMeta, 'io.modelcontextprotocol/clientCapabilities': { elicitation: {} } }

This matches the intent recorded in tracking issue #296 for this check ("Call a tool that needs
sampling/elicitation, scan stream frames") and strictly widens the set of servers the check can
exercise: capability-enforcing servers become testable, and servers that ignore capability
declarations behave as before.

Additional context
Draft PR #351 refactors this same probe (shares the stream with a new check).

I have a fix with a self-test ready and verified against a real SDK per CONTRIBUTING (both
outcomes: the untestable failure without the change, 28/28 with it) and will open a PR referencing
this issue.