feat: simulate network failures

[MaxMichel2]

Summary

Add the ability to simulate network failures (timeout, connection refused, offline/no-connectivity) for a mocked endpoint, not just successful/error HTTP status responses. This is independent of the OpenAPI migration (tracked in the epic, #72) and can be picked up any time.

Current state

NetworkMockPlugin's mock path (devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt:233-292) only ever produces two outcomes for an intercepted request: a successful synthetic HttpClientCall via createMockHttpClientCall (:264-271), or a fallback to the real network (every other branch — global-off :174-180, no state :199-209, Network state :224-232, null response :274-282, exception :283-291). There is no way to make a mocked endpoint simulate the absence of a usable response — a timeout, a dropped connection, a DNS failure — which is exactly the class of error condition that's hardest to reproduce on demand during manual testing and most valuable to have mockable.

EndpointMockState (devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/model/NetworkMockState.kt:204-262) is a sealed interface with exactly two variants today: Network and Mock(responseFile). Delay simulation already exists as a separate, working mechanism (match.delayMs, resolved from Operation.delayMs ?: group.defaultDelayMs, applied via kotlinx.coroutines.delay at NetworkMockPlugin.kt:259-262) — that's a good precedent for how to wire in something similar for failure simulation, since delay already proves the plugin can inject artificial behavior before ever reaching createMockHttpClientCall.

What to build

• A new EndpointMockState/OperationMockState variant (naming depends on whether ✨ Add Renovate config #3 has landed), e.g. Failure(type: FailureType), alongside Network and Mock.
• At minimum, cover: a generic timeout (throw or delay-then-throw a kotlinx.coroutines.TimeoutCancellationException or an appropriate Ktor exception type), and a connection-refused/IO-failure simulation (throw an appropriate java.io.IOException/platform equivalent — check what a real Ktor engine actually throws for these conditions so the simulated exception is realistic enough for the app's existing error handling to exercise the right code path).
• Surface the new state as a selectable option in the endpoint detail screen (devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/NetworkMockEndpointScreen.kt) alongside the existing "No mock" / response-variant rows.

Acceptance criteria

• At least a timeout and a connection-failure simulation are selectable per operation.
• The simulated failure surfaces to the calling app as a realistic exception type — verify against what the actual Ktor engine (OkHttp/Darwin, per sample/network's actuals) throws for the equivalent real condition.
• The existing delay simulation continues to work independently (a mock can still have a delay without failing).
• Tests in NetworkMockPluginTest.kt cover the new failure modes.

Files likely touched

• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/model/NetworkMockState.kt
• devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt
• devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/NetworkMockEndpointScreen.kt
• devview-networkmock-ktor/src/androidHostTest/.../NetworkMockPluginTest.kt