[TEST] Add an opt-in NPD + NRC end-to-end compatibility suite

Motivation

While testing node-readiness transitions, I noticed that the current E2E tests update NodeConditions directly. That tests NRC in isolation, but not the production-like path:

NPD monitor -> NodeCondition -> NRC -> Node taint

Would maintainers be interested in a small, opt-in Kind E2E test for this compatibility path?

Proposed scope

Add a separate target so the existing E2E path remains unchanged:

make test-e2e-npd-kind

• Create a Kind worker with an initial readiness NoSchedule taint.
• Run a pinned stock NPD image; the NPD DaemonSet must tolerate the startup taint.
• Use a deterministic Custom Plugin to test the main lifecycle without patching NodeConditions from the test:
  • exit 0 -> problem condition False -> taint removed;
  • exit 1 -> condition True -> taint added;
  • another exit code -> condition Unknown -> taint retained;
  • recovery to exit 0 -> taint removed.
• Add one built-in SystemLogMonitor (filelog) case: a synthetic matching log changes a permanent condition to True, which NRC consumes and turns into a taint.
• Use a continuous Rule with requiredStatus: "False" and no defaultStatus, so a missing condition remains fail-closed.
• Assert the Node Ready condition is preserved and collect Node, Rule, Event, Pod, and NPD/NRC logs on failure.

The test would use bounded polling (Eventually) and pinned image versions. It would start as local/opt-in or periodic and only become presubmit-gating after stability data is available.

Non-goals

• No direct NodeCondition patching in this suite.
• No dependency on the npd-prober work in #159.
• No Descheduler/remediation flow from #201.
• No Reporter, heartbeat freshness enforcement, destructive host fault injection, or exhaustive testing of every NPD monitor.
• No new NRC API or build-time dependency on NPD.

This should complement the existing direct NRC E2E tests and the examples in #159/#201 by validating the producer-to-policy contract. Would this focused scope be useful, and should it remain opt-in or run periodically first?

/kind feature

Read the existing direct NRC E2E tests and current E2E make targets first, then evaluate the proposed make test-e2e-npd-kind entry point with Kind and pinned NPD images. Done means the opt-in suite covers the listed Custom Plugin, SystemLogMonitor, fail-closed Rule, condition-preservation, polling, and failure-log collection cases without directly patching NodeConditions.