feat: x-devview vendor extension for delay simulation

[MaxMichel2]

Part of #72

Depends on #73.

Summary

Restore the shipped delay-simulation feature inside the OpenAPI-shaped config, using an x-devview vendor extension object — the standard OpenAPI Specification Extensions mechanism (any key prefixed x-; tools that don't recognize it simply ignore it).

Why this exists

Vanilla OpenAPI has no field for "delay this response by N ms." Today's bespoke format has one: EndpointConfig.delayMs (per-operation, devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/model/MockConfiguration.kt:286) falling back to ApiGroupConfig.defaultDelayMs (per-group, :131), resolved in MockConfigRepository.findMatchingMock as matchingEndpoint.delayMs ?: group.defaultDelayMs (repository/MockConfigRepository.kt:366) and applied in the Ktor plugin via kotlinx.coroutines.delay (devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt:259-262). This is a shipped feature (closed issue #61 — "Allow configuring mock response delay from DevView UI"). None of #73–#77 give it a home in the new format — without this issue, upgrading to 0.2.0 silently regresses a working feature.

This gap was identified during a design-partner review (see epic #72's linked discussion) that also argued OpenAPI's inability to express runtime-only behavior was a reason to keep the old bespoke format. That conclusion was rejected — the identical _devview-style extension mechanism would be needed for the bespoke format too — but the underlying gap (delay needs a home) is real and is what this issue fixes.

What to build

An x-devview object (a single namespaced key, not multiple flat x-devview-* keys — leaves room to grow, see #B/#C below for what else will eventually live here), usable at two levels mirroring today's fallback:

# document root — spec-wide default, replaces ApiGroupConfig.defaultDelayMs
x-devview:
  delayMs: 200

paths:
  /users/{userId}:
    get:
      operationId: getUser
      # per-operation — replaces EndpointConfig.delayMs, overrides the root default
      x-devview:
        delayMs: 500

Resolution order: operation.x-devview?.delayMs ?: document.x-devview?.delayMs ?: null — must match today's precedence exactly (operation-level wins, falls back to document-level default, falls back to no delay).

Per #73's design constraint, this parsing lives entirely inside MockConfigRepository's implementation — the resolved Long? delay value becomes a plain field on Operation/ApiSpec (per #3's naming), never a leaked x-devview map type.

Acceptance criteria

• Parser (from feat: OpenAPI 3.x spec loader (JSON + YAML) #73) reads x-devview.delayMs at both the document root and per-operation.
• Precedence matches today's fallback exactly: operation-level overrides document-level.
• A test spec with both root-level and operation-level values confirms override behavior; a test spec with only a root-level value confirms fallback; a test spec with neither confirms no delay.
• Migration guide (docs: migration guide + mocks.json -> OpenAPI conversion script #81) documents the mapping from delayMs/defaultDelayMs to x-devview.delayMs.
• No x-devview-shaped type is visible outside MockConfigRepository's implementation (per feat: OpenAPI 3.x spec loader (JSON + YAML) #73's pure-seam requirement).

Files likely touched

• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt (or wherever the OpenAPI parser lands per feat: OpenAPI 3.x spec loader (JSON + YAML) #73)
• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/model/MockConfiguration.kt (or its post-✨ Add Renovate config #3 rename) — Operation/ApiSpec gain a resolved delay field
• devview-networkmock-core/src/commonTest/...
• docs/guides/migrating-to-openapi.md (docs: migration guide + mocks.json -> OpenAPI conversion script #81)