feat: simulate network failures

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 #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

Read NetworkMockState.kt and NetworkMockPlugin.kt first, then inspect NetworkMockEndpointScreen.kt and the existing delay handling. Use NetworkMockPluginTest.kt as the test entry point and verify the exception behavior against the Ktor engines used by sample/network. Done means timeout and connection-failure states are selectable per operation, realistic failures reach the calling app, delay still works independently, and tests cover both modes.