startupScript() lacks error recovery path to clear system.temp.Frontier.startingUp, leaving webserver hung on error #849

Rationale

startupScript() has no error recovery path that clears system.temp.Frontier.startingUp, creating a severe robustness issue. Any failure between lines 37 (setting startingUp=true) and 242 (clearing it) leaves an HTTP server that accepts connections but never responds — forever, with no self-heal mechanism. For long-running servers, this is unacceptable. This issue exists independently of Issue #XXX (the headless registry-window bug) — both should be fixed.

Current State

• startupScript.ut sets system.temp.Frontier.startingUp = true at line 37 as an idempotency guard
• No try-catch or error recovery wraps the work phase (lines 37-242)
• Any exception or failed verb call (e.g., buildMenuBar()) aborts the script mid-flight
• system.temp.Frontier.startingUp is never cleared (line 242 unreachable on error)
• Consequence: webserver enters infinite loop waiting for startingUp==false; accepts connections and hangs forever
• Idempotency guard (line 33) blocks retry: if (startingUp) { return } prevents re-entry on the next request

Compare: tools.startup (also in startupScript) properly uses try-guarding to protect its work.

Desired Outcome

Guarantee system.temp.Frontier.startingUp is cleared on all exit paths from startupScript(), whether success or failure. Long-running servers remain responsive even if startup encounters recoverable errors.

Recommendation

Wrap the main work (lines 37-242) in a try-finally block to guarantee cleanup. Alternatively, try-guard each high-risk call (e.g., buildMenuBar()) and ensure local error recovery does not leave startingUp set. Example pattern:

local (ok = true);
try {
    buildMenuBar();
} catch (exception) {
    log.add(exception);
    ok = false;
}
if (!ok) { system.temp.Frontier.startingUp = false; return false; }

Exit Criteria

• startupScript() has a try-finally or equivalent error recovery that clears startingUp on all paths
• No exception or failed verb call leaves system.temp.Frontier.startingUp set
• Webserver remains responsive if startup encounters an error
• Integration tests cover startup failures (e.g., missing menu files)

Related Context

• Related: Issue #XXX (registry-window bug is the trigger in 3.1, but this issue is independent hardening)
• Similar pattern: tools.startup uses try-guarding; startupScript should match
• Scope: UserTalk robustness, startup path