feat: surface cached client update notices in command responses #67

Problem

Agents and scripts often consume only session-peer's command response and do not
run session-peer update --check separately. A newer stable release can therefore
remain invisible even though the response was produced by an outdated client.

Checking GitHub on every invocation would add latency, rate-limit pressure, and
an unnecessary failure dependency to message delivery. Remote commands also need
to distinguish the invoking client version from the separately reported remote
standalone installation.

Proposed behavior

• Check the latest stable GitHub release on a bounded schedule, with a dedicated
  local cache and a conservative default TTL such as 24 hours.

• When a newer version is known, add structured metadata to machine-readable
  responses, for example:

  {
    "clientUpdate": {
      "schemaVersion": 1,
      "status": "available",
      "current": "0.6.2",
      "latest": "0.6.3",
      "checkedAt": "2026-09-15T10:00:00Z",
      "source": "github_release_cache",
      "command": "session-peer update"
    }
  }

• Add a short human-readable update notice without corrupting JSON stdout.

• Keep clientUpdate scoped to the invoking CLI. Preserve remoteVersion and
  remote update results as separate destination-installation facts.

• Give package-managed installations correct pipx, uv, or pip guidance instead
  of claiming that the standalone self-updater will replace them.

• Let session-peer update --check force or refresh the authoritative check and
  populate the same cache.

• Provide an opt-out for air-gapped or tightly controlled environments.

Reliability and compatibility

• Version-check timeouts, malformed responses, GitHub outages, cache permission
  errors, and offline operation must never change the primary command result or
  exit code.
• Do not make message submission wait on a slow version endpoint. Perform at
  most one local check per invocation and never repeat it once per SSH target.
• Write cache updates atomically with user-only permissions and do not store
  credentials, command payloads, hosts, or session identifiers.
• Keep existing JSON fields and shapes compatible. Coordinate any broader
  top-level envelope redesign with --json output can't say which host it came from, and the shape differs per command #29.
• Use stable, non-draft, non-prerelease GitHub releases and strict semantic
  version parsing.

Acceptance criteria

• A cached newer stable version produces a structured clientUpdate notice.
• Current, unknown, offline, malformed, and expired-cache cases are explicit
  and do not affect the primary command outcome.
• Human and JSON output remain independently parseable.
• Multi-host commands perform no per-host release lookup and keep
  remoteVersion semantics unchanged.
• Standalone and package-managed installations receive actionable guidance.
• Tests cover cache freshness/expiry, atomic writes, timeouts, invalid
  versions, opt-out behavior, multi-host calls, and failure isolation.