[API Proposal]: Add stateful resource mocks (ForResource<T>) and/or scenario state transitions

## Motivation

`ThenRespondsWith(...)` (#115) handles a sequence of responses from *one* mock, but state is never shared *across* mocks. The very common case — POST creates a resource, a later GET returns it, a DELETE makes it 404 — still has to be wired by hand with custom matchers and captured closures.

## Proposed API

Two possible shapes, in rough order of preference.

**Resource mocks (more idiomatic for Mockly):**

```csharp
mock.ForResource("/api/users")
.WithSeed(existingUsers)
.KeyedBy(u => u.Id);

// GET /api/users -> 200, seeded collection
// POST /api/users -> 201 + Location, item added
// GET /api/users/{id} -> 200 or 404
// DELETE /api/users/{id}-> 204, subsequent GET is 404
```

**Scenario/state machine (WireMock-style), for the cases a CRUD collection does not cover:**

```csharp
mock.ForGet("/api/job").InState("pending").RespondsWithJsonContent(pending);
mock.ForPost("/api/job/start").TransitionsTo("running");
mock.ForGet("/api/job").InState("running").RespondsWithJsonContent(running);
```

## Notes

- `ForResource` removes a lot of boilerplate for anyone testing a client against a REST collection.
- Needs a clear story for `Reset()` / `Clear()`: does the seeded store reset too?
- Both should stay compatible with `CollectingRequestsIn` and the existing assertions.

Start by reviewing the existing ThenRespondsWith(...) behavior from issue #115 and the compatibility requirements for CollectingRequestsIn and existing assertions. Define whether the change is a stateful ForResource API, a scenario state machine, or both, including Reset()/Clear() behavior; done means the chosen API supports the described create, read, delete, and state-transition flows with tests.

Written by the indexing model from the issue text.