[API Proposal]: Add real socket listener mode (mock.StartServer()) for non-HttpClient callers

## Motivation

Mockly intercepts at the `HttpMessageHandler` level. That is the right default: it is fast, needs no ports, and works everywhere. But it means Mockly cannot see any traffic that does not go through an injectable `HttpClient`:

- third-party SDKs that own their transport or construct clients internally
- code in another process (a spawned worker, a container, a CLI under test)
- libraries that only accept a base URL, not a handler

This is the main capability gap versus WireMock.Net, and it currently forces people to reach for a second mocking library alongside Mockly.

## Proposed API

An opt-in in-process listener that reuses the exact same mock configuration:

```csharp
var mock = new HttpMock();
mock.ForGet("/api/users").RespondsWithJsonContent(users);

await using var server = mock.StartServer(); // binds 127.0.0.1 on a free port
sdk.BaseUrl = server.Url;

mock.Should().HaveAllRequestsCalled();
```

## Notes

- Same matching, same capture, same assertions — only the transport differs.
- Should bind to a random free port by default, with an overload to pin one.
- Loopback only by default, for obvious security reasons.
- Separate package: needs a real HTTP server (`HttpListener` or Kestrel), which should not be a core dependency, and is unlikely to be worth supporting on `net472`.

Start by reviewing the existing HttpMock configuration, matching, capture, and assertion behavior, then assess how the proposed StartServer() entry point can reuse it without adding a core dependency. Done means a separate package provides loopback binding on a free or pinned port, exposes server.Url, preserves existing request behavior, and documents the net472 support boundary.

Written by the indexing model from the issue text.