fix(http): enforce Origin validation semantics

[lucarlig]

Adds opt-in strict Origin validation while preserving the existing default and non-empty allowlist behavior.

Motivation and Context

When Origin validation is enabled, malformed and non-UTF-8 Origin headers currently return HTTP 400 instead of the specification-required HTTP 403.

This change adds enforce_origin_validation() so servers can reject every present Origin when the allowlist is empty without changing the current default. Requests without an Origin header continue to pass. The conformance server opts into strict validation explicitly.

Closes #1191 and includes the malformed-Origin fix from #1188.

How Has This Been Tested?

• cargo fmt --all -- --check
• Focused custom-header integration tests: 29 passed
• Conformance-server test: 1 passed
• Server conformance suites for protocol versions 2025-11-25 and 2026-07-28

Tests cover allowed, disallowed, absent, malformed, and non-UTF-8 Origins; enforced empty allowlists; explicit disabling; and legacy compatibility paths.

Breaking Changes

None. Strict empty-allowlist validation is opt-in. Existing default and non-empty allowlist behavior are preserved.

When validation is enabled, malformed and non-UTF-8 Origins now return HTTP 403 instead of HTTP 400.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Existing Origin port-matching behavior is intentionally unchanged because the MCP specification does not define allowlist matching semantics.

[lucarlig]

@DaleSeo, could you approve the first-time-contributor CI, CodeQL, and Conformance runs and review this Origin-validation fix? The intended behavior is documented in #1191, the compatibility change is explicitly marked breaking, and the CI-equivalent test suite passes locally.

[lucarlig]

Updated to address CI:

• Configured the conformance server to allow its own loopback Origin while continuing to reject untrusted Origins.
• Wrapped the commit body to satisfy commitlint.
• Verified both server conformance suites: 51/51 checks for 2025-11-25 and 115/115 for 2026-07-28.

[DaleSeo]

Thanks, @lucarlig. The fix itself looks correct.

One process note: we're between major releases right now. v3.2 is next and is planned as a minor release, so marking this !: would force a standalone v4.0.0 just for this PR, which we'd rather avoid.

Could you rework this as a non-breaking change? Keep the current default as is, and put the spec-compliant behavior behind an opt-in, such as enforce_origin_validation(). We'll switch the default in a future major release.

[lucarlig]

thank you for the review @DaleSeo. Makes sense, I changed it as requested.