feat: hub self-decided upgrade check via POST /api/upgrade

[william0wang]

Summary

• POST /api/upgrade lets a remote client TRIGGER the hub's staleness check;
  the restart decision is entirely the hub's own. It restarts onto the on-disk
  code only when that code is NEWER than the running process:
  • on-disk package.json version beats the version frozen at process start, or
  • any dist/**/*.js mtime (floored to ms — APFS sub-ms fractions would
    otherwise beat a truncated Date.now()) is later than process start, so a
    rebuild without a version bump counts.
• On restarting: true the hub replies, closes (~500ms), re-spawns itself
  from its own dist path (bin/hub.ts respawnSelf), and exits; bridges
  re-register on their next heartbeat and EADDRINUSE keeps the respawn race
  a machine singleton. A respawned process starts after the newest dist mtime,
  so the check self-negates — no restart loops, and an OLDER disk version
  never triggers.
• The existing newer-bridge handshake now uses the same restart path
  (onRestart, falling back to onIdleExit when unset).

Test plan

• 6 new cases in tests/hub.test.ts: 401, version-bump restart, mtime
  (rebuild) restart, same-version no-op, older-version no-op, and safe
  defaults on the real repo layout.
• Full suite 696/696, tsc --noEmit, eslint, prettier clean.
• docs/REMOTE-CLIENTS.md — new "Hub self-upgrade" section + endpoint row.

Release 0.11.7.