[Bug] `check` always reports "Updates available" while `update` reports "Skills are up to date" in the same tree

Summary

impeccable check reports "Updates available." for an install that is already current. In the same tree, one second later, impeccable update --global -y reports "Skills are up to date (v4.3.1)."

Both verbs exit 0, so there is no signal that separates "genuinely outdated" from "already current" — the check verb appears to be unconditional.

Environment

• Skill bundle: v4.3.1 (installed to user level: ~/.claude, ~/.gemini, ~/.agents, ~/.pi)
• Engine: scripts/VERSION = 0.1.5, installed per-harness at <skill>/scripts/bin/linux-x64/impeccable
• OS: Linux 6.8.0 x86_64, Node v22.23.2 (launcher only)

Reproduction

$ cd ~
$ ~/.agents/skills/impeccable/scripts/impeccable check
Checking for updates...

Updates available.
Run `npx impeccable update` to update.
# exit 0

$ ~/.agents/skills/impeccable/scripts/impeccable update --global -y
Updating the user level install: ~ (.claude, .gemini, .agents, .pi)
Checking for updates...
Skills are up to date (v4.3.1).
Installed hooks into: .claude, .agents
Nothing else to do.
# exit 0

$ ~/.agents/skills/impeccable/scripts/impeccable check   # same verdict, immediately after a no-op update
Updates available.

Controls that all still print Updates available.:

1. Fresh synthetic home — HOME=/tmp/fakehome containing only a verbatim copy of the current 4.3.1 bundle at .claude/skills/impeccable + .agents/skills/impeccable and no ~/.impeccable state (no update-check.json).
2. Deliberately stale tree — 4.0.4 bundle in the same layout: identical output, i.e. the verb does not discriminate between 4.0.4 and 4.3.1.
3. Network disabled — HTTPS_PROXY=http://127.0.0.1:9 HTTP_PROXY=http://127.0.0.1:9 impeccable check: still "Updates available", so the verdict is not coming from a successful remote comparison.
4. Project-level scope is unaffected — from a directory with no harness folders (/tmp, a git checkout) it correctly prints Impeccable is not installed in this project.; only the user-level/user-level-detected tree yields the false positive.

Probe that suggests the cause

The installed binary answers --version with a different version domain than the bundle it shipped with:

$ ~/.agents/skills/impeccable/scripts/bin/linux-x64/impeccable --version
4.0.0
$ cat ~/.agents/skills/impeccable/scripts/VERSION
0.1.5
$ grep -m1 '^version:' ~/.agents/skills/impeccable/SKILL.md
version: 4.3.1

Hypothesis (unverified from the outside): check compares a version it reads from the engine/binary build (or from a cached update-check.json value) against the installed skill-bundle version, so the two never match and the answer is always "available". Note update itself compares correctly, which is why the two verbs disagree.

Impact

• Any automation or user habit of gating on impeccable check (cron, CI, pre-commit, "is my harness current?") gets a permanent false positive and will re-run update forever.
• check returning exit 0 in both the current and the outdated case means exit status can't be used as a substitute gate either.
• Because check/update disagree, users can't tell whether a genuine update exists — the "Updates available" notice in my ~/.impeccable/update-check.json is indistinguishable from this false positive.

Expected

check against a current user-level install prints an up-to-date message (and ideally exits non-zero only when an actual newer release exists).