feat(conformance): mark provider-supplied leaves in expected responses

[e54-bot]

Summary

Closes #49. Rebased onto main after #51 (refactor/conformance-tooling-seams) merged.

Expected responses used verbatim JSON equality, so the six session templates and inline handshake scenarios pinned reference-mock identity (serverInfo, languages, capability values, supportedProtocolVersions) and provider prose (error.message, refusalCode, provider-defined details.reason). This change introduces a provider-leaf marker:

• A leaf written { "$provider": "<kind>" } in expectResponse asserts the leaf's contract shape instead of a literal. Four kinds cover every spec-declared provider-supplied position: nonEmptyString (serverInfo fields, error prose, refusalCode, unenumerated reason), boolean (capability values), languageList (the languages array), protocolVersions (supportedProtocolVersions as MAJOR.MINOR strings).
• matcher.rs owns the recursive compare with path-aware mismatch errors. Fixture validation enforces the marker positions as a whitelist — a marker on a contract-owned leaf (protocolVersion, error.code, an enumerated invalidRequest reason, an undeclared capability id) is a fixture error, with sibling context (data.lpp.kind, negotiated protocolVersion) deciding positions that are provider-supplied only under some error kinds.
• capabilities semantics follow §7.3: a provider may advertise any subset (absent == not offered), so missing keys are exempt at that position while undeclared ids still fail the closed-set check. A marked capabilities object must cover exactly the ids declared for the negotiated version. §7.2's "requires the eight fields" wording is corrected to match — the object is required, its keys are any declared subset.
• Every unmarked leaf keeps verbatim JSON equality, including object key sets. Enumerated invalidRequest reasons (notInitialized, alreadyInitialized, notificationNotSupported) stay pinned — they are spec values, not provider prose.
• providerArgs remains an adapter-owned surface: scenarios carrying it keep their negotiated capability map verbatim (the false leaves are the assertion) and are not expected to run on third-party providers.
• The serverInfo.version coupling to workspace CARGO_PKG_VERSION is gone: no fixture pins lpp-mock-provider, 0.1.0, or the x-demo-lang language entry anymore.

Documented in docs/spec/conformance.md §20.1 and conformance/README.md.

Test plan

• cargo fmt --all --check, cargo clippy --all-targets -- -D warnings, cargo test --workspace (incl. 6 new matcher unit tests)
• --validate-only: 61/61 pass
• Full suite vs lpp-mock-provider: 61/61 pass — no behavioral change for the reference adapter
• Independent acceptance: a scratch Python stub provider (different language id, name, version, prose) passes all 10 protocol-scope scenarios that exercise neither x-demo-lang semantics nor providerArgs — fixture content unchanged
• git diff --check

[Teakowa]

Three contract-correctness findings block merge. CI is green, but the current matcher can both weaken normative fixtures and reject/accept provider results inconsistently with the v1 spec. Please resolve these against the owning spec before retargeting/merging.

[Teakowa]

The three previous findings are resolved. One regression remains in the new capability-subset matching path.

[Teakowa]

LGTM