Defer backend client setup until after first paint (fixes #75)

[techut30]

Problem

Fixes #75 — app hangs on launch (0% CPU, never draws a window) on macOS 26.2.

main.swift configures the backend clients before NSApplication.run():

Log.bootstrap()
Telemetry.start()
BundledFonts.register()
AccountService.shared.configure()   // constructs ConvexClientWithAuth + Clerk.configure
ModelCatalog.shared.configure()     // reads AccountService.shared.convex

AccountService.configure() synchronously constructs the Convex (Rust-FFI) / Clerk network clients on the main thread, before the run loop starts. If that construction blocks, app.run() is never reached, so AppKit never connects to the window server and no window is ever created. The process stays alive at 0% CPU (a blocked synchronous wait), never signals launch, and is eventually flagged "not responding" — with no crash report and no window. That matches the issue exactly (lsappinfo shows !cgsConnection !signalled).

None of this work is needed to draw the home window.

Change

Move both configure() calls out of the pre-run() path and into applicationDidFinishLaunching, after the window is shown, on a deferred main-actor Task so first paint can't be blocked by backend-client construction:

// Configure backend clients after first paint so a slow or unreachable
// backend can't block the window from appearing (issue #75).
Task { @MainActor in
    AccountService.shared.configure()
    ModelCatalog.shared.configure()
}

• Ordering preserved: ModelCatalog.configure() reads AccountService.shared.convex, and configure() sets convex synchronously before returning, so calling them sequentially in the same task keeps the dependency intact.
• No earlier dependency: neither the home window (HomeView binds AccountService.shared via @Observable and already tolerates the pre-load / signed-out state) nor MCPService.start() reads convex/ModelCatalog, so moving config a beat later is safe.
• On a healthy machine, behavior is unchanged — account/model state just populates one run-loop turn later, which the UI already handles since these are async anyway.

Testing

I was not able to build/run locally (only have Swift 5.10 / Command Line Tools here, not the Swift 6.2 + Xcode 16 toolchain), and I couldn't reproduce the hang deterministically — the app is hardened-runtime signed, which blocks sample/spindump/lldb introspection, so I diagnosed from the launch architecture rather than a captured stack. The change is small and ordering-preserving; a maintainer build/run on macOS 26.x would be the real confirmation. Happy to adjust (e.g. also defer Telemetry.start() / MCPService.start(), or bracket each startup step with an os_log marker so a future launch hang is immediately attributable) if you'd prefer a different shape.