Keep standalone runtime monitoring out of Pod-metadata retries #4717

🤖 Generated by the Agentic Engineer

Description

Kubescape's runtime callbacks request Kubernetes Pod metadata for standalone runtime containers that have no Pod identity. This produces failed metadata retries and stops the rule-manager registration before its normal monitoring lifecycle. Keep standalone monitoring separate from Kubernetes enrichment instead of suppressing the resulting errors.

Steps to Reproduce

1. Register a non-host, standalone runtime container with an empty Kubernetes namespace and Pod name.
2. Exercise the real container-watcher and rule-manager callbacks with bounded fake Kubernetes/cache dependencies.
3. Observe the Pod lookup with an empty identity and the rule-manager wait for shared Kubernetes metadata that cannot be populated.

These steps describe a required regression reproduction, not a claim that an executable regression test has already been completed.

Expected Behavior

Standalone registrations retain their supported context and monitoring lifecycle without asking for a nonexistent Kubernetes Pod. Genuine Kubernetes registrations keep their enrichment, retries and failure reporting. Removal and shutdown terminate the affected registration cleanly.

Actual Behavior

The public container-watcher callback bypasses Pod enrichment only for the virtual host container. The rule-manager entrypoint likewise bypasses its shared-data wait only for that host identity, although the context detector explicitly supports standalone registrations. The same distinction remains in upstream main at this investigation.

Acceptance Criteria

• Reproduce both callback failures with the real entrypoints before changing behavior; distinguish standalone identity from delayed or incomplete Kubernetes enrichment.
• Correct the owning implementation with narrowly scoped lifecycle tests, including removal/re-add and shutdown where relevant.
• Preserve virtual-host monitoring, real Kubernetes metadata errors, runtime alert delivery and every existing security check; no severity downgrade or collector disablement.
• Carry the reviewed fix through a reproducible, pinned and signed platform image if an upstream release is not yet available.
• Validate CI, current-head review, merge and deployment; verify a fresh observation window and actual monitoring coverage rather than only the absence of log errors.

Additional Context

Part of #2447. This is separate from the exited-container and API-conflict classification handled by the existing compatibility patch. Public evidence is limited to upstream source and synthetic reproduction design; production logs, identities and topology remain private. Upstream contribution authority is being requested separately.