There's a classic two phase commit problem here. For all stub
modifications, WireMockApp first mutates StubMappings, then calls
MappingsSaver to persist the change. If the call to MappingsSaver
fails to persist the change then what is running, and what is persisted,
are out of sync until the persisted changes reload.

There is of course no 100% robust solution to committing transactions on
two independent data stores. However, catching any exception in the
calls to MappingsSaver and reverting the in-memory changes to
StubMappings seems superior to not doing so.

The fix moves persistence into AbstractStubMappings itself. Each
mutation method now follows the pattern: run before-listeners, update
the store, attempt to save via protected save()/remove() hooks,
revert the store silently on failure, and only then run after-listeners.
StoreBackedStubMappings overrides the hooks to delegate to a
MappingsSaver. This means after-listeners which trigger external
side effects  only fire once the save has succeeded, and rollback
is a direct store revert with no listener involvement.

WireMockApp.addStubMapping(), editStubMapping(), and
removeStubMapping() are now simple delegations to StubMappings.

It is of course possible that the changes were, in fact, persisted
despite the exception being thrown; in which case the running state and
the persisted state will still be out of sync. I believe there is no
solution to this - it could be further mitigated by rechecking, but not
ultimately solved.

Breaking change: third-party implementations of StubMappings that
extend AbstractStubMappings will inherit the new behaviour
automatically. **Direct implementors of the StubMappings interface will
lose the save behaviour that WireMockApp previously provided**, and will
need to implement it themselves if required.

Introduce InMemoryStubMappings (non-saving) alongside StoreBackedStubMappings
(saving) to cleanly separate persistence from in-memory operations. Both share
the same underlying store and scenarios.

WireMockApp now uses InMemoryStubMappings as a load target so that loading
mappings from disk never triggers a save back. StoreBackedStubMappings handles
all persistence internally via save/remove hooks, eliminating direct
MappingsSaver usage from WireMockApp operations (saveMappings, resetMappings,
importStubs, removeStubMappings).

The updateMappings bulk operation now persists inserted/removed stubs with
rollback on failure, matching the pattern already established for addMapping,
editMapping and removeMapping. After-listeners only fire after successful
persistence.

The previous name didn't communicate that this StubMappings instance
must only be used for loading stubs from files (where persistence
should be skipped to avoid re-saving stubs already on disk).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Save and remove stubs to disk before applying scenario updates
and in-memory store mutations, so that persistence failures are
caught before the system state has changed.