fix(reload): no-downgrade guard + advance shared-server on update

Two structural fixes for the 'force reload downgrades the client to an
old server version' problem:

1. Updates now advance the shared-server channel (the daemon's reload
   target) when it was merely tracking stable, so updates are actually
   picked up by the long-lived server. A deliberately-promoted self-dev
   shared-server build is left untouched so updates never silently wipe
   it out (advance_shared_server_if_tracking_stable).

2. reload exec gains a hard no-downgrade guard: a forced reload will
   never exec into a binary strictly older than the running one; it
   re-execs the current binary instead. Same-or-newer candidates
   (including fresh self-dev builds) still apply.

Adds unit tests for both the tracking helper and the guard decision.