fix(server): make "server has newer binary" directional, not channel-mismatch (#291)

`server_has_newer_binary()` started with a `version_matches_installed_channel`
shortcut that returned `true` whenever the running server's version/git-hash did
not match the installed `stable`/`current` channel markers. That conflated
*different* with *older*: a newer self-dev or shared-server daemon (e.g.
v0.17.23-dev) running next to an older release client would be told it had an
"update" and prompted to reload/downgrade itself, because a release build had
moved the channel markers to a different git hash. It also fed the reload-loop
family (#277): a server that merely "differs" can never make the difference go
away by reloading, so it would keep being told to reload.

The server only ever reloads onto `shared_server_update_candidate` (shared-server
channel or stable, never the fast-moving `current` channel), and `UPDATE_SEMVER`
is the same base version for every dev build, so it cannot order two dev builds.
Binary mtime is the only robust directional signal. Drop the mismatch shortcut
and rely solely on `newer_binary_available`, which already requires a candidate
to be *strictly newer* (and excludes reloading into ourselves, and treats any
unreadable mtime as "no update").

Net effect: a newer/dev server reports "no update" and the release client
attaches cleanly with no downgrade nag, while a genuine upgrade (channel binary
with a newer mtime) still triggers a reload. Adds unit tests for the #291
scenario and the equal-mtime no-loop case.