Split /__aimock/reset into explicit /__aimock/reset/fixtures and /__aimock/reset/journal

[jpr5]

Problem

POST /__aimock/reset clears the in-memory fixture/matcher index. This is by design, but the name is ambiguous and it's a footgun: a caller who intends to reset only the request journal (e.g. to get a clean read between test runs) ends up wiping the loaded fixtures. After that, aimock returns no_fixture_match (503/404) for every request until the fixtures are reloaded (container restart).

This silently wedged a D6 showcase ramp run: a clean-journal call to /__aimock/reset nuked the fixture index, and every subsequent pill failed to match — masquerading as conveyance/test failures until we restarted aimock.

Proposal

Make the reset target explicit:

• POST /__aimock/reset/fixtures — clears/reloads the in-memory fixture index (current /__aimock/reset behavior).
• POST /__aimock/reset/journal — clears only the request journal, leaving fixtures intact (the common "clean read between runs" intent).
• POST /__aimock/reset — deprecated alias mapping to /__aimock/reset/fixtures for now (preserves current behavior; emit a deprecation notice in the response/logs).

Alternative considered

A single POST /__aimock/reset?target=fixtures|journal|all query-param form. The explicit sub-paths read more clearly and are more RESTful; noting the query-param option only as an alternative.

Notes

• GET /__aimock/journal is already GET-only (read snapshot) — good; this is only about the destructive reset surface.
• Observed on aimock v1.27.3.