ResponseMessage.DateTime defaults to DateTime.MinValue, causing premature log entry purging for *matched* requests

[PeterBenko]

Describe the bug

When Response.Create() is called without a pre-built ResponseMessage, the resulting ResponseMessage.DateTime property is left at its default(DateTime) value (0001-01-01T00:00:00).
This causes matched request log entries to be immediately purged when RequestLogExpirationDuration is configured.
Unmatched requests are not affected because their responses are built internally by IResponseMessageBuilder, which now sets the timestamp correctly -> #1454.

Expected behavior:

Matched responses built with the default Response.Create() should not get instantly purged.

Test to reproduce

• Configure a WireMock server with RequestLogExpirationDuration set (e.g., 24 hours)
• Register a mapping using Response.Create().WithStatusCode(200) (no explicit ResponseMessage)
• Send a request that matches the mapping
• Query /admin/requests shortly after — the log entry for the matched request is already gone
• Send a request that does not match any mapping — its log entry is retained correctly

Workaround

On server side, callers can use WithCallback to create a new ResponseMessage with DateTime.UtcNow at request time:

.RespondWith(Response
    .Create()
    .WithStatusCode(200)
    .WithBodyAsJson(myBody)
    .WithCallback(_ => new ResponseMessage
    {
        DateTime = DateTime.UtcNow,
        BodyData = builder.ResponseMessage.BodyData
    }));

I could not find a workaround that would work when creating the Mapping via the REST client

[StefH]

#1487