fix: allow spec reload

Start in devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt, reading cachedConfig and loadConfiguration(). Trace NetworkMockViewModel.loadConfiguration() and the existing Reset to Network action in NetworkMock.kt if considering UI exposure. Done means invalidation causes a later load to re-read and re-parse changed resource content, with downstream configuration refreshed as needed.

Summary

MockConfigRepository caches its parsed configuration forever after the first successful load, with no way to invalidate the cache and force a re-read. This is independent of the OpenAPI migration (tracked in the epic, #72) and can be picked up any time.

Current state

MockConfigRepository.loadConfiguration() (devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt:201-254) checks cachedConfig (declared at :125) first and returns it immediately if present (:205-210), never re-reading the underlying resource. There is no method to clear this cache. In practice this means the mock configuration (mocks.json today, an OpenAPI spec after the migration in #72) can only ever be reloaded by restarting the process — there's no way for a developer to edit the config/spec file and see the change reflected without a full app restart, which is a meaningfully worse dev-loop than most things this tool is meant to speed up.

What to build

• Add a way to invalidate/clear cachedConfig, either as a new public method (e.g. invalidateCache() / reload()) or as a parameter on loadConfiguration() (e.g. loadConfiguration(forceReload: Boolean = false)).
• Decide whether this should be surfaced in the UI (e.g. the existing "Reset to Network" toolbar action pattern in NetworkMock.kt:131-158 is a reasonable precedent for adding a second toolbar action, "Reload config") or left as a repository-level API for now, and note the decision in the PR.
• Consider whether reloading needs to also re-run registerEndpoints/response-discovery downstream (NetworkMockViewModel.loadConfiguration(), devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/viewmodel/NetworkMockViewModel.kt:138-193) — likely yes, since a changed config could add/remove/rename operations.

Acceptance criteria

• There is a way to force MockConfigRepository to re-read and re-parse its underlying resource after the first load.
• Calling the invalidation path and then reloading picks up changes to the underlying file (test with a resource loader stub that returns different content on a second call).
• If surfaced in the UI, it follows the existing "Reset to Network" action pattern for consistency.

Files likely touched

• devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt
• devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/NetworkMock.kt (if surfaced in the UI)
• devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/viewmodel/NetworkMockViewModel.kt (if surfaced in the UI)