feat: serve response headers declared in the spec

First check the status of the OpenAPI migration in epic #72/#1. Then inspect MockResponse.kt and createMockHttpClientCall in NetworkMockPlugin.kt, followed by the existing assertions in NetworkMockPluginTest.kt. Done means declared response headers reach the app, while Content-Type still defaults to application/json unless explicitly overridden.

Summary

Mocked HTTP responses returned by NetworkMockPlugin always carry only a Content-Type: application/json header, with no way to declare additional headers per mock. This is independent of the OpenAPI migration (tracked in the epic, #72) and can be picked up any time — though if the OpenAPI migration (#1) has already landed, this becomes a natural fit for OpenAPI's responses.<code>.headers field, so check the epic's status before starting.

Current state

createMockHttpClientCall (devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt:322-346) builds the synthetic HttpResponseData with a hardcoded single header:

headers = headersOf(
    name = HttpHeaders.ContentType,
    value = ContentType.Application.Json.toString()
),

(:332-335). There is no mechanism anywhere in MockResponse (devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/model/MockResponse.kt:79-84) or the config format to declare additional response headers (auth challenge headers, caching headers, custom headers a client depends on, etc.) for a mocked response.

What to build

• If done before the OpenAPI migration lands: extend the current mocks.json format with an optional headers field per endpoint/response.
• If done after the OpenAPI migration (#1) lands: this maps naturally onto OpenAPI's standard responses.<code>.headers object — prefer that over inventing a new mechanism, since it's already a standard field this parser will otherwise ignore.
• Thread declared headers through MockResponse and into createMockHttpClientCall's headersOf(...) call, merging with (not replacing) the existing Content-Type default unless a mock explicitly overrides it.

Acceptance criteria

• A mocked response can declare headers beyond Content-Type.
• Declared headers appear on the response the app actually receives (add a Ktor plugin test asserting header presence, alongside the existing status/body assertions in NetworkMockPluginTest.kt).
• Content-Type still defaults to application/json when a mock doesn't declare it explicitly.

Files likely touched

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