feat(preflight): check capabilities and kernel before loading BPF

[maxgio92]

xcover run checks its environment before loading any BPF object so unsupported hosts get an actionable error instead of libbpf's bare "invalid argument". Missing CAP_BPF and CAP_PERFMON (or CAP_SYS_ADMIN) in the effective set is a hard failure that names the missing capabilities. A kernel release older than 6.6 is an advisory only, because distribution kernels backport uprobe_multi (RHEL 9.4 ships it on 5.14). --skip-preflight bypasses both checks and --userspace-bpf implies it.

Table tests cover the release parser, the capability decision and the skip paths.

[dodoazzurro]

Reviewed #191 (adds internal/preflight — kernel version advisory + capability check before BPF load).

Logic checks out:

• ParseRelease handles distro suffixes correctly (6.12.0-1-amd64 → 6.12, 6.18.44-r0-gcp-6.18 → 6.18), and the test table covers the tricky cases (6.6-rc1, non-numeric major/minor, empty string, bare "6").
• Kernel check is advisory-only (logs a warning, never blocks) — correct, since backports (RHEL 9.4/5.14) can't be detected from the version string alone.
• Capability check is the actual gate: CAP_SYS_ADMIN alone short-circuits as sufficient, otherwise both CAP_BPF and CAP_PERFMON are required — matches how the perfmon/bpf cap split works (pre-5.8 kernels only had CAP_SYS_ADMIN for bpf()).
• --userspace-bpf correctly implies skipping preflight (no kernel BPF path involved there).

One thing worth a second look: daemonize() calls o.preflight() once in the parent (to fail fast before forking) and then the re-exec'd daemon calls it again via Run() → setup() → preflight(). Not wrong, just means the check — and any kernel advisory warning — fires twice when detaching. Harmless (cheap syscalls) but slightly redundant logging in the daemon's log file.

Nothing blocking.

[maxgio92]

Fixed: preflight now runs once when detaching. The child gets --skip-preflight because the parent has just run the same checks with the same credentials.

Also on this branch:

1. The e2e harness skips on the capability error when unprivileged instead of failing.
2. The setcap hint names the binary and says file capabilities do not apply under go run or nosuid mounts; the kernel advisory no longer recommends the skip flag, which would also disable the capability check.
3. README keeps the "reports ready with 0% coverage" caveat until fix: fail loudly instead of writing a wrong report #185 lands.