Fix concurrent scenario mapping removal - #3596

Concurrent scenario mutations currently perform separate read/modify/write operations. When two stubs from the same scenario are removed concurrently, both removals can read the same original scenario and write stale replacements, leaving one removed mapping behind.

This change serializes the scenario mutation entry points while keeping read-only operations lock-free. It also adds a deterministic regression test that coordinates two concurrent removals and verifies that the scenario is deleted after its final mappings are removed.

References

• Fixes NullPointerException during removal of stubbing having a scenario #1999

Testing

• ./gradlew :test --tests com.github.tomakehurst.wiremock.stubbing.ScenariosTest
• ./gradlew spotlessCheck :test --tests com.github.tomakehurst.wiremock.stubbing.ScenariosTest
• ./gradlew check
• git diff --check

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org (not applicable; this is a bug fix)