Launch AdminUI helper threads outside the constructor (CodeQL java/thread-start-in-constructor)

[vharseko]

Summary

Resolves both java/thread-start-in-constructor alerts in AdminUI (lines 234
and 247). The AdminUI() constructor started two threads:

• a frame-building thread (creates the JFrame/splash, then setupFrame()),
  joined before the constructor returned; and
• a host-name lookup thread (InetAddress.getLocalHost()), fire-and-forget.

Both are anonymous Thread subclasses that capture this, so they could observe
AdminUI before its construction finished — the exact pattern the rule warns
about (most dangerous if the class is subclassed and a helper thread calls an
overridden method against uninitialised subclass state).

Change

The thread block is moved verbatim from the constructor into a new
public void launch() method, and main() calls it right after construction:

final AdminUI adminUI = new AdminUI(rmiHost);
adminUI.launch();
if (rmiHost != null) {
    adminUI.connect(rmiHost);
}

AdminUI is only ever instantiated by its own main() (verified across the
repo — the other UI classes just hold a reference handed to their setup(ui)
methods), so moving the launch out of the constructor affects no other caller.

Behaviour

The main() sequence is unchanged: construct (records the RMI host) → launch()
(builds the frame, waits for it, kicks off the host-name lookup) → connect().
The frame is still fully built before connect() runs, so the RMI connection and
window title behave exactly as before. The connect() call previously performed
inside the AdminUI(String) constructor now runs from main() after launch();
refresh() already guards _tabbedPane != null, so the remaining convenience
constructors stay safe.

Testing

mvn -o -pl persistit/ui compile — BUILD SUCCESS.