docs(startup): correct the rationale for the deferred server start

The comment justified deferring btnStartClick by the taskbar-proxy exposure
window, which the .dpr fix has since removed. Kept as-is per decision — it
works and reaching the tray sooner is desirable — but the comment now says
that, so nobody "fixes" it later against a premise that no longer holds.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

delphi-backend/UMainForm.pas

@@ -334,15 +334,17 @@ begin
     end;
   end;
   // Starting the server (DB open + Indy bind + WebView2 navigation) is what
-  // makes FormCreate run for ~1 s. The FMX taskbar proxy is created somewhere
-  // inside that second, and since the thread never pumps a message while it
-  // runs, nothing can hide the proxy until it is over — that is the taskbar
-  // button sitting there during the Windows logon.
+  // makes FormCreate run for ~1 s. On a --tray launch it therefore runs AFTER
+  // the tray hide, in the deferred block below, so FormCreate returns in
+  // milliseconds and the app is tray-resident right away.
   //
-  // On a --tray launch, do it AFTER the tray hide instead: FormCreate then
-  // returns in milliseconds, MinimizeToTray runs immediately, and the proxy is
-  // gone before it can be drawn. A normal launch is unchanged (the window is
-  // meant to be on screen anyway, so ordering does not matter there).
+  // NOTE: this was originally needed to shrink the window during which the FMX
+  // taskbar proxy was visible. That is no longer the reason — the proxy is now
+  // dealt with properly in the .dpr (StartTrayProxyHider, WS_EX_TOOLWINDOW).
+  // The ordering is kept because it works and reaching the tray sooner is
+  // desirable, NOT because anything depends on it. A normal launch keeps the
+  // original order. FServer is constructed earlier (see above), so FServer.Active
+  // reads False rather than faulting while the start is pending.
   if not FindCmdLineSwitch('tray', True) then
     btnStartClick(Nil);
   btnToggleLogClick(nil);