fix: recover OMP executable after installation path changes

[ha5h6r000wn]

Problem

Switching OMP installation channels, such as Homebrew to the official curl installer, leaves PinkCollab pointing to a stale absolute executable path even when a working installation is available on PATH.

Root cause

Setup validates the persisted executable without a controlled rediscovery mechanism. Explicit-path resolution intentionally does not fall back to PATH, and doctor does not identify a replacement.

Solution

• Preserve valid configured executables without probing a PATH replacement.
• Validate a PATH replacement with the existing bounded omp --version probe and require authorization before migration. Interactive confirmation defaults to No; explicit setup --omp <path|omp> also authorizes non-interactive recovery.
• Compare stable executable entries before candidate validation so the same failed launcher is not probed twice. Do not canonicalize symlink targets.
• Enhance read-only doctor diagnostics with the configured failure, PATH candidate, validation result, and recovery instructions. Database diagnostics neither create nor migrate databases, including older databases without a lease table.
• Reuse the existing service installation/update flow: its fingerprint already includes configuration, so an OMP change refreshes a running Gateway without an extra restart path. Repeated unchanged setup does not rewrite configuration or restart the service.
• Document recovery and preserve existing settings, workspace roots, pairings, and saved session records.

Compatibility

No changes to executable resolver fallback semantics, Runtime launch behavior, Windows PATHEXT handling, runtime protocol, Android, networking, dependencies, lockfiles, or database schema.

Tests

Final verification on macOS using an isolated Rust 1.89.0 toolchain matching upstream CI (the user's default toolchain was not changed):

• cargo fmt --check: passed.
• cargo clippy --all-targets --all-features --locked -- -D warnings: passed.
• cargo test --all-features --locked: 234 passed, 2 ignored across 24 suites.
• Latest targeted external-setup/service-lifecycle regression: 1 passed.
• New single-probe regression failed before the correction and passed afterward; covers setup and doctor with bare-name and stable-symlink configuration entries.
• Standalone CLI smoke confirmed setup and doctor each probe the same failed symlink entry once, retain configuration, and do not create a database. Earlier isolated PTY smoke exercised interactive refusal and consent.
• git diff --check: passed.

The previously observed strict Clippy failure on Rust 1.98.1 is an existing chunks_exact_to_as_chunks warning at unchanged upstream src/service/windows_ux.rs:148. It was not fixed or suppressed in this PR; CI's Rust 1.89.0 strict check passes.

Native Ubuntu, macOS, and Windows Gateway CI checks passed on commit 2d58c4659ce3e41f6364277cf9a0db056f6fc7b3, including formatting, strict Clippy, the full test suite, and the Gateway build. npm checks on all three platforms, website, and ci-required also passed: CI run 38237443478. Android and release-cache were conditionally skipped.

CLI/service regressions use temporary homes, fake executables and service managers; these CI tests are not end-to-end acceptance of production systemd, launchd, or Windows services. Real service changes and a real OMP smoke test were not performed. Existing symlink-upgrade regressions pass. One initial local targeted run hit the existing health fixture socket-read timeout; the rerun and full suite passed without relaxing the fixture or assertions.

Notes

A required Gateway restart terminates active OMP runtimes but preserves pairings and saved sessions. If restart fails, setup reports failure and retains the authorized configuration; resolve the service error before restarting. No runtime protocol, network, or Android changes are included.