Point every build at the hosted server, not just the ones that ship

The default was split on DEBUG so a clone would offer localhost and only an
installed build would offer ssh.dodotech.cloud. That protected development
launches from enrolling a device against production. It also meant the address
in the box depended on how the binary was built, which is not what was wanted.

Working against a local API now means typing http://localhost:5233 by hand.

src/DodoSSH.Client.Shell/ViewModels/MainWindowViewModel.cs

@@ -418,25 +418,21 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
     /// </summary>
     /// <remarks>
     /// <para>
-    /// Two defaults, because the two audiences never overlap. A release build is installed by somebody
+    /// One default for every build. The hosted deployment is what all but a handful of launches are
-    /// signing in to the hosted deployment, and typing its address is the only thing standing between
+    /// aiming at, and typing its address is the only thing standing between an installed application and
-    /// them and a working application. A debug build is run from a clone, next to
+    /// a working one. Running against a clone means replacing this with
-    /// <c>dotnet run --project src/DodoSSH.Api</c>, and shipping the hosted address there would point
+    /// <c>http://localhost:5233</c> by hand — note the scheme, because the API's first launch profile —
-    /// every development launch at production — which is worse than an inconvenience, since sign-in is
+    /// the one a plain <c>dotnet run</c> and the README both select — is plaintext on 5233, and pointing
-    /// the step that enrolls a device.
+    /// an HTTPS client at a plaintext port fails as "The SSL connection could not be established", which
-    /// </para>
-    /// <para>
-    /// Note the schemes. <c>http</c> locally is not an oversight: the API's first launch profile — the
-    /// one a plain <c>dotnet run</c> and the README both select — is plaintext on 5233, and pointing an
-    /// HTTPS client at a plaintext port fails as "The SSL connection could not be established", which
     /// sends people looking for a certificate problem. See <see cref="ExplainSignInFailure" />.
     /// </para>
+    /// <para>
+    /// This was once split on <c>DEBUG</c> so a development launch could not enroll a device against
+    /// production by accident. That protection is gone: a debug build now offers the hosted address like
+    /// any other, and the first sign-in accepted unread lands there.
+    /// </para>
     /// </remarks>
-#if DEBUG
-    internal const string DefaultServerUrl = "http://localhost:5233";
-#else
     internal const string DefaultServerUrl = "https://ssh.dodotech.cloud";
-#endif
 
     [ObservableProperty]
     private string serverUrl = DefaultServerUrl;

tests/DodoSSH.Client.App.Tests/ShellFlowTests.cs

@@ -303,20 +303,15 @@ public sealed class ShellFlowTests : IAsyncLifetime
     /// application is not running.
     /// </para>
     /// <para>
-    /// Both branches are written out rather than compared against the constant itself. Asserting a
+    /// The address is written out rather than compared against the constant itself. Asserting a constant
-    /// constant against itself would pass however it were edited, and the whole point of this test is
+    /// against itself would pass however it were edited, and the whole point of this test is that no
-    /// that a release build must not ship a developer's loopback address — or, since the split, that a
+    /// build ships a developer's loopback address.
-    /// debug build must not point a clone at production.
     /// </para>
     /// </remarks>
     [Fact]
-    public void TheDefaultServerUrl_IsTheHostedDeployment_ExceptInADebugBuild()
+    public void TheDefaultServerUrl_IsTheHostedDeployment_InEveryBuild()
     {
-#if DEBUG
-        shell.ServerUrl.ShouldBe("http://localhost:5233");
-#else
         shell.ServerUrl.ShouldBe("https://ssh.dodotech.cloud");
-#endif
     }
 
     [Theory]