fix: validate and forward SEP-2243 parameter headers

[lucarlig]

Summary

• validate modern tools/callMcp-Param-* headers against request-scoped tool schemas published by the control plane
• return JSON-RPC -32020 for a mismatch or missing published schema
• forward validated parameter headers unchanged on the outgoing tools/call and protect them from backend header configuration
• keep plugin handling unchanged: plugins run after validation and do not cause header reconstruction

The dataplane does not call tools/list, reconstruct headers from arguments, or change RMCP. This PR requires IBM/mcp-context-forge#6348 to publish visibility-filtered schemas keyed by original upstream tool name.

The GitHub composed conformance job still pulls the stock control-plane image and therefore fails to deserialize its pre-#6348 payload (missing field tool_schemas). No dataplane fallback is included; the job will pass once #6348 is merged into that image.

Stacked on #107. Related: IBM/mcp-context-forge#6256.

Verification

• cargo clippy --locked --workspace --all-targets -- -D warnings
• cargo nextest run --locked --workspace (227 passed, 3 skipped)
• workspace build, dependency-policy, shear, formatting, generated-schema, and wiki checks
• conformance adapter, reporter, and baseline unit tests
• control-plane publisher unit tests (26 passed), Ruff, and Black
• cross-repo E2E with the official conformance fixture and #6348 publisher: matching plain/Base64 values pass; mismatched, invalid Base64, and missing headers return JSON-RPC -32020

The direct fixture E2E is used because the official server scenario currently reaches the separately baselined stateless tools/list session limitation during setup. Client findings remain limited to the existing four shell-adapter generation IDs.

[dawid-nowak]

1. I don't see how checking the max body size of the message is a part of header validation logic. Ideally, body size validation should be in a separate layer and re-using layers provided by Axum.

2. This header validation logic only applies to tools. Not sure if using a layer approach is valid as this is going to be executed on all rmcp calls as well as new and old protocols.

[dawid-nowak]

I think you should move validation to tools/call handler.

1. If something is not right with the request rmcp will validate it anyway.
2. You can easily get access to all necessary headers via:
   let downstream_headers = cx.extensions.get::().map(|parts| &parts.headers);
3. Everything related to tool call is in one place.
4. Not sure if this header is auto propagated to upstream so you might need to do it manually.

[lucarlig]

Addressed in ef71cba:

• moved SEP-2243 parameter validation into the tools/call handler
• read downstream headers from RMCP request-context Parts
• removed the parameter-validation middleware and duplicate Axum body-limit handling; RMCP owns envelope/body validation
• kept explicit transparent Mcp-Param-* forwarding in upstream transport setup
• covered modern mismatch/missing-schema rejection and the legacy-protocol bypass