GUI: open the window before the startup SNTP sync

[sidick]

Addresses the parked symptom in #71 — "passphrase requester closes, then no window appears" — with a root cause, a deliberate on-target reproduction, and a fix. (Not closing #71 automatically; see below for what remains of it.)

Root cause

The startup SNTP sync sat between the passphrase requester and win_show, and it can block far longer than the nominal 5 s UDP timeout: clock_sntp_sync calls gethostbyname(), whose timeout belongs to the TCP/IP stack's resolver, not us — against a dead/black-holed DNS server that's routinely tens of seconds. With a stack running but the network down (a typical Amiberry test-session state), the requester closed and then nothing appeared until the resolver gave up. This also explains why the symptom "hasn't been seen recently": no stack configured → bsdsocket open fails instantly → sync skips.

This displaces the parked LISTBROWSER-relist theory: the first relist paints ------ placeholders (cheap); the network block was sitting directly in the reported gap.

Reproduction (deliberate, on-target)

Two instrumented builds with an identical 30 s Delay() injected at the sync call site, run through gui-smoke's window assertion with the screenshot at t=35 s:

• Old ordering + stall: bare desktop, unique_colours=1 — the reported symptom, verbatim.
• New ordering + same stall: window up and painted (placeholders in the code column, amber "Clock: manual" status), stall running behind it.

The fix

Move the sync to right after win_show (and refresh the status line + LED immediately on success rather than waiting for the next tick). Worst case is now a visible, briefly unresponsive window instead of an invisible hang. Placement detail: the sync stays before the public-port AddPort, so a CLI launched during a slow sync falls back to its local path exactly as before — registering the port earlier would instead make forwarded requests block on the unserviced port.

A fully async sync (subprocess) would remove even the brief unresponsiveness, but that's real machinery for a window that's normally sub-second; noted as a possible future refinement.

What this does and doesn't settle in #71

• The stuck-broker limitation is already documented in Troubleshooting (confirmed unfixable; reboot).
• This PR explains and fixes the remaining parked symptom — but since it was never reliably reproducible in the wild, I'd suggest keeping Abnormal exit (crash/hard-kill) leaves a stuck commodity broker, silently blocking all future launches until reboot #71 open only if you want the killtask dev tool committed (it was never checked in and isn't on disk); otherwise this closes the loop.

Verified

make test (194), make gui-smoke (normal, non-instrumented), mkdocs build --strict + make guide clean. Docs updated in-branch: Troubleshooting gains "window ignores clicks briefly after unlocking", Time-and-Clock-Sync notes the new ordering.

🤖 Generated with Claude Code