Fix Duplicate Upgrade Prompt in CLI

Root-caused it — your hypothesis is close but the mechanism is different: nothing shells out to entire --version. It's the parent entire process's own post-command version check, running with its stale compiled-in version.

What happened, step by step:

1. upgrade isn't a built-in, so the old binary (0.8.43-nightly.20260708...) dispatched to the entire-upgrade plugin (cmd/entire/cli/plugin.go:41). The plugin ran brew and successfully upgraded the binary on disk.
2. When the plugin exits 0, the parent mirrors Cobra's PersistentPostRun and runs the version check: versioncheck.CheckAndNotify(ctx, os.Stderr, versioninfo.Version) at plugin.go:52. But that parent process is still the old binary, so versioninfo.Version is the pre-upgrade version baked in at compile time.
3. Your 24h check cache (~/.config/entire/version_check.json) had expired, so it fetched the latest nightly, saw 202607081321 < 202607110651 → "outdated" (versioncheck.go:86), and showed the interactive huh "Update available!" prompt. That's the second "do you want to upgrade" you saw (the huh TUI erases itself after selection, which is why it's not in your transcript).
4. You picked "Update now", which printed Updating Entire CLI: brew upgrade --yes entire@nightly (autoupdate.go:87) and re-ran brew — a no-op, since the plugin had already installed the new version.

The bug: the post-plugin version check compares the running process's compiled-in version against latest, but the plugin may have just replaced the binary on disk. The check is answering "is this process stale?" when the question that matters is "is the install stale?" — and after entire upgrade, the answer to the first is always yes.

Fix options, in order of my preference:

• Skip CheckAndNotify when the plugin is upgrade (or any official upgrade-ish plugin). One line in MaybeRunPlugin, trivially correct. Slight coupling to the plugin name, but the official allowlist already exists (IsOfficialPlugin).
• Re-check the on-disk binary before prompting: before showing the prompt, stat/exec-resolve os.Executable() isn't enough — you'd have to actually read the new binary's version, which means spawning it. Ironically that's the entire --version subprocess you hypothesized. More robust (covers a user running brew upgrade in another terminal mid-session), but heavier.
• Have the plugin bump the cache: entire-upgrade writes LastCheckTime (and could clear SkippedVersion) into version_check.json on success. Works, but couples an external binary to the parent's cache format — fragile across versions.

Also worth noting: MaybeAutoUpdate unconditionally offers the brew path even though the fetched latestVersion is what the check just saw — after choosing "Update now" and getting brew's "already installed" warning, we still print "Update complete" (autoupdate.go:92), which is misleading in this case, but that's cosmetic once the root cause is fixed.

Want me to implement the skip-after-upgrade-plugin fix?

Done — committed as 5e12b0cac on inherited-snacking-squirrel (not pushed).

What changed:

• cmd/entire/cli/plugin.go — MaybeRunPlugin now skips versioncheck.CheckAndNotify when the plugin that just ran is upgrade (new selfUpdatePluginName const), since the parent process's compiled-in version is stale by definition after a self-update. The call goes through a new postPluginVersionCheck seam var for testability.
• cmd/entire/cli/plugin_test.go — three new tests: version check fires after a successful non-upgrade plugin, is skipped after entire-upgrade succeeds, and is skipped after any plugin fails (pre-existing behavior, now pinned).

Verification: all plugin tests pass; mise run fmt && mise run lint clean (0 issues), git diff after lint showed only my two files.

One tradeoff to be aware of: this is name-based coupling — a third-party entire-upgrade on PATH that doesn't upgrade the CLI would also suppress the check. I think that's fine since the name is de facto reserved for the official plugin, but flag it in the PR if you want it noted.