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/PMServer.dproj

@@ -204,7 +204,6 @@ $(PreBuildEvent)]]></PreBuildEvent>
         <Icon_MainIcon>PMServer_Icon1.ico</Icon_MainIcon>
         <UWP_DelphiLogo44>app.png</UWP_DelphiLogo44>
         <UWP_DelphiLogo150>app.png</UWP_DelphiLogo150>
-        <Debugger_RunParams>-tray</Debugger_RunParams>
     </PropertyGroup>
     <ItemGroup>
         <DelphiCompile Include="$(MainSource)">

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
+  // makes FormCreate run for ~1 s. On a --tray launch it therefore runs AFTER
-  // inside that second, and since the thread never pumps a message while it
+  // the tray hide, in the deferred block below, so FormCreate returns in
-  // runs, nothing can hide the proxy until it is over — that is the taskbar
+  // milliseconds and the app is tray-resident right away.
-  // button sitting there during the Windows logon.
   //
-  // On a --tray launch, do it AFTER the tray hide instead: FormCreate then
+  // NOTE: this was originally needed to shrink the window during which the FMX
-  // returns in milliseconds, MinimizeToTray runs immediately, and the proxy is
+  // taskbar proxy was visible. That is no longer the reason — the proxy is now
-  // gone before it can be drawn. A normal launch is unchanged (the window is
+  // dealt with properly in the .dpr (StartTrayProxyHider, WS_EX_TOOLWINDOW).
-  // meant to be on screen anyway, so ordering does not matter there).
+  // 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);