Issue #1188 — Catching a Stale pipx CLI Before It Misleads You

The Broader Goal at the End of the Previous PR

The CLI should make the state of a multi-agent workspace legible and actionable, including failures caused by the tool installation itself.

What This PR Shipped

When synlynk is invoked from inside a synlynk checkout, the CLI now locates the checkout's VERSION file and compares it with the running package version. If the installed binary is behind, it prints a stderr warning identifying both versions and gives a concrete pipx install --force command to refresh the installation. The check is local, best-effort, and silent for non-synlynk directories, malformed metadata, and versions that are already current.

What This Achieved on the Path to Autonomy

It removes a subtle source of operator confusion: a repository can now explain when the command being used is older than the code the operator is inspecting. That shortens diagnosis time for stale pipx environments without blocking normal commands or requiring a network probe.

Strategic Note: The Goal at the End of This PR

Keep the CLI self-diagnosing at the boundary between installed tooling and live workspace state, while preserving a quiet path for ordinary use.