Fix phantom accelerating state after reboot (autostart shows running but never starts)

[showtimewwx]

Problem

On macOS, when "开机自启" (launch-at-login) is enabled, after a reboot the GUI shows "加速中" (accelerating) but acceleration is actually not working. Toggling acceleration off/on fixes it until the next reboot.

Root cause (verified with logs)

Timeline from operations.log of an affected boot:

[t0]       privileged-helper: 特权辅助守护进程启动，开始监听 socket
[t0 … t0+110min]  (nothing — no helper-start, no traffic, yet UI shows "加速中")
[user]     helper-stop → helper-start → acceleration actually starts

Chain of events:

1. When acceleration runs, handle_helper_start writes the helper process's own pid into the pid file (state::write_pid + state::mark_running). The helper is started very early by the root LaunchDaemon, so its pid is small.
2. Nothing clears the state/pid files on shutdown, so running: true survives the reboot.
3. After the reboot the stale small pid is very likely reused by an unrelated process (system daemons get low pids first). platform::is_process_running only probes with kill -0 (a root-owned pid also succeeds via the EPERM branch) and never checks which process owns the pid, so state::refresh() rewrites the stale state into running: true, "加速中，PID <reused pid>".
4. gui.rs::maybe_autostart sees self.status.running == true and returns early, never sending the real start request.

Black-box reproduction without rebooting: write 1 (launchd) into the pid file, set running: true in service-state.json, run linuxdo-accelerator status — v0.1.16 reports "running": true, "status_text": "加速中，PID 1".

Fix

1. platform.rs — after the liveness probe succeeds, verify the pid actually belongs to this application via ps -p <pid> -o comm= matching the linuxdo-acceler prefix (15-char comm truncation on Linux compatible). A recycled pid owned by an unrelated process is now treated as not running.
2. service.rs — run_privileged_helper reconciles state once at startup via state::refresh(). At that point this helper has not started any proxy, so any leftover running state is guaranteed stale; this fixes it before the GUI reads it.

Verification

• With the forged stale state (pid=1/launchd): v0.1.16 reports running: true; this patch reports running: false, "已停止" and cleans the state file.
• Regression: a pid pointing to the real application process is still correctly reported as running.
• End-to-end: reproduced the boot scenario (same command line as the LaunchAgent, --autostart gui, with the forged stale state) — the patched GUI correctly starts acceleration (helper-start fires, DNS takeover applies, UI shows 加速已生效) instead of being fooled by the stale state.

[showtimewwx]

Pushed two more commits that fix a CPU spike reported after running the patched build for a while:

• 0d188d5 runtime_log.rs: read_recent_lines read the entire operations.log on every UI refresh — the log grows without bound while the proxy runs (observed at 113MB after a few months), which cost ~80% CPU with acceleration on. It now seeks to the tail and parses a fixed 64KB window, and append rotates the log at 8MB (keeping one .1 generation).
• db1841a gui.rs: ensure_launcher_viewport re-issued 4 viewport commands every frame, which made winit emit resize events every frame and kept egui repainting at full speed (~11% CPU even when idle). The commands are now only sent when the window size actually drifted.

Measured on the reporting machine: GUI CPU drops from 83% to ~0.5%, both idle and with acceleration running.