Guard local remove against running servers in any project

[sdairs]

What

local remove's running-server guard was project-scoped: it called recover_current_project_servers() and filtered list_running_servers(), both of which only see .clickhouse/servers/ under the current working directory. A server started from another project directory was invisible, so local remove <its-version> exited 0 and deleted the binary from under it — the server kept running on its open fd, but local client -n <name> in that project then failed with managed_client_binary_not_found (issue #600).

The guard now enumerates running servers across every project using the same process-discovery machinery behind local server list --global, merged with this project's metadata and de-duplicated by PID:

• Both sources are consulted because each covers a gap in the other: metadata is project-scoped but survives a failed process scan, while discovery spans projects but depends on pgrep/lsof//proc.
• A single discovery pass feeds both orphan recovery and the global view, so the guard does not shell out to pgrep/lsof twice (recover_from_discovered_locked / global_entries).
• A discovered process whose version cannot be read is treated as non-matching — blocking every removal on an unreadable command line would be unfixable by the user.

Why the error and --force changed shape

• Refusal is still exit 1 / JSON server_running, but the message now names each blocking server as '<name>' in <project-root> (PID <pid>), in both the human error and the structured one, and points at clickhousectl local server list --global. Without the project root, a blocker outside the current directory is unactionable.
• --force stops blockers wherever they run: through metadata in this project (so the recorded state stays consistent) and by PID elsewhere, exactly like server stop --global. Its confirmation line now names the project.

Tests

• src/local/server.rs unit tests for the pure helpers select_version_users (no match, other-project match, same server via both sources reported once, merge of both sources, unreadable version, Postgres container never matching a ClickHouse version) and describe_version_users.
• New subprocess suite crates/clickhousectl/tests/local_remove_global_guard_test.rs: isolated HOME, three fake installed versions, two project dirs, and deterministic pgrep/lsof/ps stand-ins on PATH (same technique as local_server_state_machine_test.rs, so the scan can never see or kill anything else on the machine). Covers the refusal, the structured error and its command, --force stopping the other project's server before removal, the unchanged same-project path (including metadata left at pid: 0), and an unrelated version still removing cleanly while the other project keeps running.
• All four cross-project tests fail against the previous guard (verified by stashing the handler change).
• cargo fmt --all, cargo clippy --workspace --all-targets -- -D warnings, cargo test -p clickhousectl all clean.

Docs

README.md and the local remove agent help now state that the check spans every project and that the error names the project root and PID.

Stacked PR

Part of a stacked chain: this PR is based on fix/599-local-remove-default-guard (the default-version guard in the same function), not main.

Fixes #600

🤖 Generated with Claude Code