Add explicit local and remote service controls

[Yan-ShiBo]

What changed

• Added explicit userscript actions for choosing the project server, initializing a local Ollama model, and starting the local service.
• Added the per-user localreadtranslate://start Windows protocol, single-instance tray wakeup, and safe register/unregister commands.
• Added lazy Kokoro loading, source-aware local/remote Ollama behavior, SSH key/agent support, Direct API mode, proxy bypass, and strict known_hosts verification.
• Removed silent local-to-remote fallback and hardened stale SSH-port and local-health identity checks.
• Updated setup, CI, English/Chinese docs, Greasy Fork guidance, design records, and the iteration 4 release record.

Why

The browser needed user-controlled source selection and a reliable way to initialize or start the correct local components without exposing remote credentials. Startup also needed to avoid allocating local TTS GPU memory for translation-only workflows.

Impact

Local translation remains the default. Remote processing begins only after an explicit project-server selection. The browser continues to call only 127.0.0.1:5000; SSH credentials stay in the tray process. Existing plain Ollama model names remain backward-compatible.

Root cause

The previous flow coupled service availability, model initialization, and source fallback too loosely: the userscript could cross the local/remote boundary implicitly, the tray had no browser-addressable start signal, and Kokoro was loaded eagerly at API startup.

Verification

• Python: 196 passed, 15 subtests passed
• Node userscript: 33/33 passed
• Python/JavaScript syntax, catalog sync, FFmpeg validation, dependency check, and git diff --check: passed
• Real Windows checks: first protocol launch, existing-tray event wakeup, no duplicate tray, /health with tts_model_loaded=false, strict-host-key SSH reconnect, and remote qwen3:30b health availability