bug: Race condition: stale localStorage token/URL used before Tauri's hostInfo arrives

[pedrohx26]

Summary

On startup, the UI reads the server token and URL from localStorage before Tauri's async hostInfo event delivers the fresh values. The first requests use stale credentials from the previous session, causing brief auth failures and a "Not connected" flash on every launch.

To Reproduce

1. Launch OpenWork
2. Observe brief "Not connected" or "limited" state in the UI (1–3 seconds)
3. After hostInfo arrives, the UI reconnects with the correct token
4. On slow systems, the disconnected state can last longer

Expected behavior

The UI should either:

• Wait for hostInfo before making server requests
• Use optimistic retry with the Tauri-provided token
• The server should accept the stale token during a startup grace period

Actual behavior

The UI immediately reads stale server.token and baseUrl from localStorage. The first /capabilities check fails with 401 (stale token) or connection refused (stale port). The UI briefly shows "Not connected" on every single launch.

OW version & Desktop info

• OpenWork: 0.11.194-1 (AUR)
• OS: Arch Linux x86_64

Additional context

Workaround: a background loop (every 3s) extracts the live --token from the running server process and writes it to localStorage:

BUN_TOKEN=$(pgrep -af "bun.*--port 878" | grep -oP '(?<=--token )[a-f0-9-]{36}' | head -1)
TOKEN_HEX=$(python3 -c "import sys; t=sys.argv[1]; print(t.encode('utf-16-le').hex())" "$BUN_TOKEN")
sqlite3 "$LS_DB" "UPDATE ItemTable SET value=X'${TOKEN_HEX}' WHERE key='openwork.server.token';"

The same loop also aligns baseUrl and server.active with server.urlOverride.