fix: treat killpg EPERM on reported provider groups as exited

[minglong51]

Problem

test_provider_probe collector-cleanup tests flake on the macOS CI runner (twice: main 08-28 run 33147669569, PR #25 run 33362589984) with:

PermissionError: [Errno 1] Operation not permitted   # os.killpg
provider_probe.ProbeError: provider-termination-failed
AssertionError: "^collector-termination-forced$" does not match "provider-termination-failed"

A reported provider pgid outlives the group it names: once every member is dead, the id can be recycled by another user's process, and killpg on it returns EPERM. macOS pid randomization makes that reuse fast on a busy runner; Linux's sequential pids explain why only macOS hits it.

Change

The probe spawns provider groups under its own uid, so a group it still owns is always signalable. In the three raw-pgid helpers (_process_group_exists, _signal_process_group, and through them _wait_for_process_group_exit), EPERM now means "the id no longer names our group" — exited — instead of raising provider-termination-failed. The Popen-based _terminate_provider_group keeps its EPERM failure: its leader pid is held un-reaped, so it cannot be recycled.

Verification

• python3 -m unittest tests.test_provider_probe: 18 OK × 3 runs; full unit group 122 OK
• Deterministic check with os.killpg mocked to raise EPERM: all three helpers report the group as gone; ESRCH behavior unchanged
• The flake itself is timing-dependent and cannot be forced; CI history adjudicates

🤖 Generated with Claude Code

https://claude.ai/code/session_01GJRuZLJk4cT5dvakGL1Wgy