v0.1.13

Fix update-button staleness and Running→Error status flapping (#24)

* Re-check npm registry periodically for omniroute updates

check_for_update only ran once at the end of bootstrap(), so a release
published while the app sat in Running was never noticed until the next
app relaunch. That's why an adopted instance (fresh launch = fresh
bootstrap = fresh registry check) showed the update button while a
long-running spawned instance did not.

Add a 30-minute recheck loop, spawned once at app setup (not in
bootstrap, which re-runs on Restart Server and would leak a loop per
restart). It only nudges Running/UpdateAvailable states, never
clobbering Starting/Updating/Error.

* Re-check for updates when recovering from a slow cold start

bootstrap() only runs check_for_update when wait_ready succeeds within
20s. On a fresh spawn (e.g. after killing both the tray and omniroute),
a slow cold start lands in Error, monitor_health later flips it back to
Running — but the update check was skipped and never retried. That is
the exact repro: adopted instance shows the button (ready=true is
instant, check always runs), while a spawned-after-kill instance does
not. Run check_for_update on the recovery transition too.

* Stop flapping Running->Error on a single busy health probe

Opening settings with a cold cache fires get_rate_limits, which walks
/api/providers plus one sequential /api/usage/{id} per account. That
keeps omniroute's single event loop busy long enough for the health
monitor's 2s probe to miss — and one missed probe flipped the state to
Error, then straight back to Running on the next poll.

Two fixes: the monitor now uses server_responding (any HTTP reply means
alive — a degraded health status is still a responding server), and it
requires 3 consecutive missed probes (~15s) before declaring Error.
Recovery stays immediate. wait_ready/server_present keep the strict
server_healthy check, which is right for startup readiness.