feat: probabilistic failure-rate injection

[MaxMichel2]

Part of #72

Depends on #A (the x-devview vendor extension mechanism).

Summary

Add probabilistic failure injection: an operation can be configured so that a percentage of requests to it fail, independent of which mock response is currently selected. This is a new capability — nothing in DevView supports it today, in either the bespoke JSON format or the OpenAPI-based one being built.

Why this is distinct from #88

Issue #88 ("simulate network failures") is deterministic: once a failure mode is selected for an operation, every request to it fails that way, the same way #EndpointMockState.Mock always serves the same response. This issue is probabilistic: a request to the operation independently rolls against a configured rate, so (for example) 1 in 10 requests fails and the other 9 succeed normally with whatever mock/network behavior is otherwise configured. The two are complementary, not overlapping — #88 answers "make this endpoint always fail right now", this issue answers "make this endpoint flaky, the way a real degraded service is."

Verified: this doesn't exist anywhere today

Targeted search across devview-networkmock-core and devview-networkmock-ktor for failureRate, randomFailure, probability, errorRate, and similar found zero relevant hits. EndpointConfig/Operation has no such field, EndpointMockState/OperationMockState is a two-variant sealed interface (Network/Mock) with no probabilistic concept.

What to build

• Extend the x-devview object (from #A) with a failureRate: Double field (0.0–1.0), at the operation level (a global/document-level default may or may not make sense — recommend operation-level only for a first pass, since "some percentage of everything fails" is a much blunter tool than "this specific flaky endpoint fails sometimes").
• When an operation has failureRate configured, each intercepted request independently rolls against it in the Ktor plugin, before the normal mock/network branching in NetworkMockPlugin.kt — regardless of whether the roll happens on a "would otherwise be mocked" or "would otherwise be live" request (decide and document which; recommend: the rate applies to mocked requests, since that's the safe, no-real-network-impact default consistent with this epic's general stance on runtime behavior — see the deferred version-forcing issue for the analogous reasoning about not touching live traffic by default).
• Inject the random source, don't call Math.random()/platform-default directly — tests need to pin the outcome deterministically (a fake/seeded source that always "hits" or always "misses").
• Surface failureRate in the endpoint detail screen (feat: rework the NetworkMock UI for specs and versions #79) as an additional field alongside the response-variant picker, not as a replacement for it.

Acceptance criteria

• An operation can declare a failure rate via x-devview.failureRate.
• The failure roll is independently evaluated per request, using an injectable random source.
• A test with a fake random source pinned to "always fail" and one pinned to "always succeed" both behave correctly; a statistical test (many iterations, checking the observed rate is within a tolerance of the configured rate) is a reasonable addition but not a substitute for the deterministic tests.
• The endpoint detail screen surfaces the configured failure rate (read-only display is acceptable for a first pass; in-UI editing is not required unless it fits naturally into feat: rework the NetworkMock UI for specs and versions #79's work).

Files likely touched

• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt (parsing, alongside #A)
• devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt (the roll + injectable random source)
• devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/NetworkMockEndpointScreen.kt

[github-actions]

This issue is stale because it has been open for 21 days with no activity.