Fix false server/runtime mismatch from installed wrapper

[capt-marbles]

Summary

• Compare installed jcode wrapper candidates against their sibling jcode-linux-x86_64.bin for reload identity and mtime checks.
• Keep reload exec targets unchanged, but prevent wrapper mtimes from masquerading as newer server binaries.
• Add a regression test for installed wrapper comparison.

Problem / reproduction

On a release install, the channel candidate is the small jcode shell wrapper, while the daemon is actually running jcode-linux-x86_64.bin after the wrapper execs it. In my local install, both client and server were on v0.18.4, but the wrapper mtime was slightly newer than the real binary:

current/jcode -> versions/0.18.4/jcode
versions/0.18.4/jcode                  2026-06-02 17:59:34.709...
versions/0.18.4/jcode-linux-x86_64.bin 2026-06-02 17:59:34.708...

Because server_has_newer_binary() compared the wrapper mtime to the running executable mtime, the server could report server_has_update: true even though it was already running the installed binary version. The TUI then showed:

Server/runtime mismatch detected; reloading server before attach

Edge cases / tradeoffs

• Reload still execs the original candidate path, so the wrapper continues to set up LD_LIBRARY_PATH for bundled libraries.
• The new comparison helper only special-cases an installed candidate named jcode when a sibling jcode-linux-x86_64.bin exists. Other paths keep existing behavior.
• This does not weaken genuine update detection: a newer real sibling binary still has a newer mtime and will be reported as an update.

Test

• cargo test -p jcode-app-core newer_binary_tests -- --nocapture

Note: full cargo fmt --check currently reports unrelated formatting drift in other files; this PR was formatted only for the touched file with rustfmt --edition 2024 crates/jcode-app-core/src/server/util.rs.