fix: kill_holder honors safety guards and verifies SIGKILL

[hc-ui]

Library kill_holder used to skip kill_block_reason (PID 1 / self / critical / service) and report SIGKILL success even when the process was still alive (D-state / unkillable).

This is a different gap from #1 (refuse killing the parent shell) and #2 (hardlink alternate paths).

Changes

• Run kill_block_reason before sending any signal so the library API cannot bypass the same guards as the CLI.
• After SIGKILL, re-check _pid_alive; still-alive processes are reported as a failure instead of a fake success.
• Windows CI fix: _windows.kill used to return success with termination requested (still shutting down) when WaitForSingleObject timed out after TerminateProcess. That is the same fake-success as the old POSIX SIGKILL path. It now re-checks _pid_exists and returns failure if the PID is still alive.
• Tests cover blocked PIDs, simulated unkillable holders, and the Windows kill backend (mocked kernel32, so Linux CI also locks that path).
• No version bump (avoids colliding with optimize: 拒绝结束父 shell（可用 --force） #1/fix: list hardlink alternate paths in holds #2).

Why Windows CI went red

Failed run: https://github.com/hc-ui/wholocks/actions/runs/32955462098

tests/test_core.py::TestKillSafety::test_sigkill_reports_failure_if_still_alive only patched os.kill / _pid_alive. On Windows kill_holder goes to _windows.kill(44444), which saw a missing PID and returned (True, "already gone"). Ubuntu stayed green because it takes the SIGKILL path.

Tests

PYTHONPATH=src python3 -m pytest -q → 70 passed locally.