feat: requestBody matching

Start with RequestMatcher.kt and MockConfigRepository.kt to understand current path, method, and query matching, then inspect NetworkMockPlugin.kt around request extraction and fallback. Define the body-matching scope and fallback behavior before implementation. Done means body-constrained operations resolve independently, unmatched bodies have documented behavior, tests cover both variants, and real-network fallback still receives the body.

Part of #72

Depends on #1, #2. Not blocking for 0.2.0 — follow-up depth issue.

Summary

Extend request matching to consider the request body shape, using the OpenAPI requestBody object, so that two operations sharing the same path/method/query but differing by payload (e.g. two variants of a POST distinguished by a discriminator field or required property) can be matched independently.

Current state

RequestMatcher (devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/RequestMatcher.kt) matches purely on path (matchesPath, :112-126, segment-based with {param} support), method (exact string equality, checked in MockConfigRepository.findMatchingMock, :331), and query parameters (matchesQueryParams, :141-149, subset match). There is no visibility into the request body at all — the plugin never reads it (devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt, request extraction at :161-167 only pulls host/path/method/query).

What to build

• Extend MockMatch/findMatchingMock (or wherever this lands post-refactor) to optionally read and match against the request body when an operation declares a requestBody schema.
• Matching strategy is worth scoping carefully before implementing — full JSON Schema validation of the body against requestBody.content.<mediaType>.schema is one option; a narrower "does this required field exist / does this discriminator field have this value" check is a cheaper and probably sufficient option for a mocking tool's purposes. Recommend starting narrow (discriminator/required-field presence) rather than a full schema validator, consistent with this library's existing "close enough for dev tooling" matching philosophy (see how lenient path/query matching already is).
• This requires reading the request body in the Ktor plugin, which today never touches it — needs care around consuming a body that may need to be re-sent if this operation ultimately falls through to the real network (the plugin's existing fallback paths, e.g. NetworkMockPlugin.kt:274-291, currently never touch the body at all, so this is new territory).

Acceptance criteria

• An operation with a requestBody schema can be matched more specifically than one without, when two operations otherwise collide on path/method/query.
• Reading the request body for matching purposes does not break the real-network fallback path (the body must still be intact if the plugin decides to execute() the real request).
• Matching strategy (narrow vs. full schema validation) is documented in the PR with rationale.
• Tests cover: two operations differing only by body shape both resolve correctly; a body that doesn't match any declared variant falls back sensibly (either no match, or match on the operation without a body constraint — decide and document which).

Files likely touched

• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/RequestMatcher.kt
• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt
• devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt