Keep the stub servers on loopback

Running the tests raised a Windows Firewall prompt, and raised it again from
every worktree. WireMockServer.Start() with no settings listens on 0.0.0.0
and [::], and the prompt is keyed to the binary that opened the socket — so
each test executable asks once per bin path, which a new worktree or a switch
between Debug and Release makes new again. The three suites that hold a
firewall rule on this machine are exactly the three that use WireMock; every
other listener in the repository already binds 127.0.0.1.

The stubs now say so explicitly. Port 0 is still WireMock's own free-port
search and still comes back on server.Url, which is what each stub builds its
base URL from, so the authority the API validates against and the issuer its
tokens claim follow the binding rather than being pinned to a host name.

Sampling the listening sockets of a full DodoSSH.Api.Tests run afterwards
finds one, 127.0.0.1, where there were previously three.

tests/DodoSSH.Client.Api.Tests/StubServer.cs

@@ -4,6 +4,7 @@ using DodoSSH.Contracts;
 using WireMock.RequestBuilders;
 using WireMock.ResponseBuilders;
 using WireMock.Server;
+using WireMock.Settings;
 
 namespace DodoSSH.Client.Api.Tests;
 
@@ -15,7 +16,14 @@ namespace DodoSSH.Client.Api.Tests;
 /// </remarks>
 internal sealed class StubServer : IDisposable
 {
-    private readonly WireMockServer server = WireMockServer.Start();
+    /// <remarks>
+    /// Bound to loopback explicitly. WireMock's default listens on every interface, which makes Windows
+    /// Firewall prompt the first time each test executable runs — and the prompt is per binary path, so a
+    /// new worktree or configuration asks again. Port 0 still picks a free port and reports it on
+    /// <see cref="WireMockServer.Url"/>.
+    /// </remarks>
+    private readonly WireMockServer server = WireMockServer.Start(
+        new WireMockServerSettings { Urls = ["http://127.0.0.1:0"] });
 
     internal Uri BaseUrl => new(server.Url!, UriKind.Absolute);