fix(update): make "update available" nag actually print

[AlephNotation]

Why

Jordan flagged in Slack that he had no idea a newer vers had shipped — the "update available" banner never printed for him. Investigation showed the startup check has been silently broken since it landed.

The bug

PersistentPreRunE in cmd/root.go did this:

if !skipUpdateCheck && update.ShouldCheckForUpdate() {
    update.UpdateCheckTime()        // (1) bumps NextCheck *before* the fetch
    go func() {                     // (2) detached goroutine
        hasUpdate, latestVersion, err := update.CheckForUpdates(...)
        if err == nil && hasUpdate {
            fmt.Printf("💡 Update available: ...")
        }
    }()
}

1. UpdateCheckTime() immediately pushes NextCheck an hour into the future.
2. The fetch runs in a detached goroutine with no synchronization.
3. Short commands like vers ps exit in ~50ms — well before the HTTP call to api.github.com finishes — so the banner never prints and the goroutine is killed mid-flight.
4. On the next run, ShouldCheckForUpdate() returns false (we just bumped NextCheck), so no check happens either.

Net effect: the nag was effectively never shown. Reproduced locally with v0.9.0 against the live v0.10.0 release — banner never appeared.

What this PR does

Replaces the racy goroutine with update.MaybeNotifyUpdate, which:

• Caches the latest known release tag in ~/.vers/config.json (update_check.latest_version). If the cached tag is newer than the running build, the banner prints synchronously with zero network I/O on every invocation. This is the path Jordan would hit on his second vers run.
• Performs a single, synchronous, bounded (800ms) HTTP refresh once per check interval — no goroutine, no race. 800ms is well below the threshold where users notice CLI lag, but enough for api.github.com from any reasonable network.
• Only advances NextCheck on a successful fetch. On failure (timeout, 5xx), uses a short 5-minute backoff so a flaky network at the moment of first launch doesn't suppress the nag for an hour.
• Skips dev/dirty builds via a centralized IsDevVersion helper (dev, unknown, dev-<sha>, *-dirty, empty).
• Does proper semver-aware comparison so v0.9.0 < v0.10.0. The previous string-equality check would also flag downgrades, which is wrong.
• Writes the banner to stderr (was stdout) so piped output of commands like vers ps | grep ... isn't contaminated.

Smoke test

Built v0.9.0 locally, pointed it at a fresh $HOME, ran twice against real GitHub:

$ HOME=/tmp/x vers ps
💡 vers update available: v0.9.0 -> v0.10.0 (run 'vers upgrade')

HEAD: 37d2f5c5-...
...
$ cat /tmp/x/.vers/config.json
{ "update_check": { ..., "latest_version": "v0.10.0" } }

$ time HOME=/tmp/x vers ps                 # warm cache
💡 vers update available: v0.9.0 -> v0.10.0 (run 'vers upgrade')
...
real    0m0.265s                            # no GitHub call

Tests

New file internal/update/update_test.go covers:

• TestIsNewerSemver — semver comparison edge cases (0.9 < 0.10, missing components, prereleases, lexical fallback).
• TestIsDevVersion — dev / dirty / unknown / clean.
• TestMaybeNotifyUpdate_PrintsFromCacheWithoutNetwork — fast path: pre-seeds cache, asserts banner prints and zero HTTP calls (httptest server fails the test if hit).
• TestMaybeNotifyUpdate_RefreshesWhenStale — slow path: stale NextCheck, fake server returns v0.10.0, asserts exactly 1 HTTP call, banner printed, cache + NextCheck updated.
• TestMaybeNotifyUpdate_NetworkFailureDoesNotSuppressForFullInterval — server returns 500, asserts NextCheck is the 5-min backoff, not 1h.
• TestMaybeNotifyUpdate_DevVersionSkipsEverything — dev build → no network, no print.
• TestMaybeNotifyUpdate_NoBannerWhenAlreadyOnLatest — same version → no banner.
• TestPrintUpdateBannerFormat — banner wording regression test (downstream onboarding docs reference the "vers upgrade" phrase).

ok  	github.com/hdresearch/vers-cli/internal/update	0.255s

Full unit test suite (make test-unit minus the unrelated tunnel integration test) passes.

Out of scope / follow-ups

• Static-linking question Jordan also raised: confirmed via file vers-linux-amd64 on the latest GitHub release — already statically linked. His dynamic copy must come from somewhere other than the Releases page (likely an older bundle inside an agent-services image). Worth pinging him for which -a vers once he installs via install.sh.
• vers upgrade itself is unchanged. Once this PR lands, users on any release ≥ this one will start seeing the nag and discover vers upgrade organically.