test(lifecycle): harden TOCTOU concurrent-Add race window (kernelevents+k8sevents)

[trilamsr]

Summary

Backport containerstdout's hardened TOCTOU race-window test pattern (#197, #209) to kernelevents and k8sevents Lifecycle_ConcurrentAddDuringShutdown_NoPanic tests. The pre-hardened tests have a brittle race window that collapses on fast schedulers — Shutdown wins universally, every Add no-ops via the closed-guard, and the test passes vacuously while never exercising the TOCTOU path it claims to cover. On slightly slower (or differently-loaded) CI machines, the same brittleness flips and produces intermittent failures, blocking unrelated PRs.

Root cause

The lifecycle's mutex guard around (closed-check, wg.Add(1)) is correct in production code. The test, however, releases all 50 adders + the shutdowner from a single gate, then relies on runtime.Gosched() alone to interleave them. On fast schedulers the shutdowner reaches lc.Shutdown(...) before any adder reaches lc.Add(...), so:

• Branch (a) "Add wins, registers under WaitGroup" never fires
• Branch (b) "Shutdown wins, Add no-ops" fires for all 50 adders
• Test passes but tests nothing meaningful
• On flip side: race window straddle changes between CI runs, surfacing as flake

Containerstdout's hardened equivalent inserts a shutdownGate channel that holds the shutdowner back until 50µs after release fires, deterministically straddling adders-in-flight with the Shutdown call. This PR ports that pattern verbatim.

Changes

• components/receivers/kernelevents/lifecycle_test.go: add shutdownGate chan + 50µs sleep + comment explaining intent
• components/receivers/k8sevents/lifecycle_test.go: same

Production code: unchanged.

Verification

for i in $(seq 1 10); do go test -race -count=1 -run ConcurrentAddDuringShutdown ./components/receivers/kernelevents/...; done
# 10/10 PASS

for i in $(seq 1 10); do go test -race -count=1 -run ConcurrentAddDuringShutdown ./components/receivers/k8sevents/...; done
# 10/10 PASS

Branch-coverage check across 10 verbose iterations (registered count <50 == branch (b) exercised):

• kernelevents: registered counts 44, 47, 49, 50, 50, 47, 44, 50, 50, 50 → branch (b) hit 6/10 iterations
• k8sevents: registered counts 49, 49, 50, 50, 50, 48, 50, 44, 48, 50 → branch (b) hit 7/10 iterations

Both branches deterministically exercised. The existing registeredCount == 0 guard in the test prevents the inverse-vacuous regression (all-no-op).

Full repo: make check clean, go test -race ./... green.

Motivation

Unblocks four in-flight PRs hitting this flake on CI:

• feat(pivot): port pyspy off internal pipeline+consumer to upstream #203
• feat(pivot): port k8sevents off internal pipeline+consumer to upstream #204
• feat(pivot): PR-B3 — port clockreceiver off internal pipeline+consumer #205
• feat(pivot): port otlphttp off internal pipeline+consumer to upstream #207

Reference

Containerstdout's port: #197 (original finding + fix), #209 (additional hardening). Same pattern applied here with no behavioral divergence.

Test plan

• make check passes locally
• go test -race ./... passes locally
• 10-iter stress on ConcurrentAddDuringShutdown in both target packages, 10/10 pass
• Verified both TOCTOU branches still exercised (branch (a) every iter; branch (b) 6-7/10 iters)
• CI green on this branch
• PRs feat(pivot): port pyspy off internal pipeline+consumer to upstream #203, feat(pivot): port k8sevents off internal pipeline+consumer to upstream #204, feat(pivot): PR-B3 — port clockreceiver off internal pipeline+consumer #205, feat(pivot): port otlphttp off internal pipeline+consumer to upstream #207 re-run + CI green after merge

NONE