Start backend automatically from macOS menu bar

[skuznetsov-clickhouse]

Summary

• Start the connection coordinator from the macOS application lifecycle, before the menu is opened.
• Discover the backend launcher from the persisted installer command, an explicit fallback, a SwiftPM source checkout, or ~/.local/bin/tokenomics-launch.
• Preserve exact-port probing, wrong-service protection, single-process ownership, and --no-open behavior.
• Add focused launcher-discovery and automatic-start coverage and update the macOS run documentation.

Root cause

Backend startup depended on SwiftUI view tasks. A MenuBarExtra label is not guaranteed to enter the view hierarchy before the user opens it, so a newly launched app could remain idle. In addition, without tokenomics-launch.json or a manually configured fallback, the existing ~/.local/bin/tokenomics-launch and source launcher were not discovered.

Verification

• node --test: 262 passed, 0 failed.
• Focused Swift lifecycle/discovery suite: 18 passed, 0 failed.
• Swift release build with -warnings-as-errors: passed.
• Runtime smoke: with port 8787 offline, the menu-bar app started launcher.js --no-open --port 8787 and /api/sync reported available=true with engine=clickhouse.
• Runtime reuse smoke: a second menu-bar process reused the ready endpoint; the process snapshot still contained exactly one launcher.js/app.js pair.
• Cleanup check: the smoke-test process group was stopped and port 8787 was closed.

Known baseline failures

The complete Swift suite is 38/40 in the current headless test environment. The two existing failures are AppKit-only assertions for NSApplication activation policy and settings-window content height. The coordinator, launcher, discovery, decoding, clock, preferences, quota, and non-headless window tests pass.

Residual risk

The coordinator prevents duplicate launch inside one app process. Two independently forced app processes starting during the same offline interval could still race before either endpoint becomes ready; normal macOS app launch does not create that situation without explicitly requesting another instance.