fix: avoid reaping unrelated processes from stale PID files

[Nishef1]

Summary

Harden crash-recovery cleanup so a stale aether.pid file cannot cause Aether-GUI to terminate an unrelated process after the operating system reuses the recorded PID.

Problem

The current startup cleanup treats a surviving PID file plus a live PID as sufficient proof that the process still belongs to Aether. PIDs are reusable, so after a crash and enough time, the same PID can belong to a completely different process.

In that situation the existing cleanup path can issue taskkill /F on Windows or kill -9 on Unix against a process Aether-GUI does not own.

Changes

• verify the executable/process name associated with the stored PID before termination
• accept only the expected upstream Aether executable name (aether.exe on Windows, aether on Unix)
• remove invalid or stale PID files without terminating unrelated processes
• keep the PID file when termination of a verified Aether process fails, allowing a later startup to retry cleanup
• suppress helper console windows for the Windows tasklist / taskkill checks
• add a focused unit test for accepted/rejected executable names

Why

A PID file is a useful recovery hint, but it is not durable proof of process ownership. Verifying process identity before destructive cleanup narrows the operation to the process Aether-GUI actually expects to own.

Scope

This PR changes only orphan-process recovery. It does not change connection establishment, tunnel behavior, route discovery, retry policy, or profile handling.

Validation

• compared against upstream main at 9ba2ef0: one commit, one changed Rust file
• manually reviewed Windows and Unix process-identification paths and stale/invalid PID behavior
• added a unit test for executable-name filtering

A Rust toolchain was not available in the connector environment used to prepare this branch, so cargo fmt, cargo clippy, and the Rust tests still need to be run before marking the PR ready for review.