Bug(fix):-Prevent nil pointer crash during early SystemMonitor initialization

[keshav78-78]

Purpose of PR

Fixes #2297

This PR addresses a startup-time nil pointer dereference in core/kubeArmor.go.
The crash happens because dm.SystemMonitor.Logger.ContainerNsKey is initialized before
SystemMonitor and its Logger are created.

This caused consistent startup panics in:

• Non-K8s mode
• K8s mode
• Early context-based shutdown tests
• Failed BPF-loader scenarios
• Policy/HostPolicy disabled flows

Fix Implemented

Initialization is now performed after InitSystemMonitor() succeeds, and additionally guarded by:

if dm.SystemMonitor != nil && dm.SystemMonitor.Logger != nil {
    dm.SystemMonitor.Logger.ContainerNsKey = make(map[string]common.OuterKey)
}

This ensures safe access regardless of mode or degraded state.

---

Startup Stability

• Proper initialization ordering between Logger → SystemMonitor → Enforcer.
• No more startup-time nil pointer crash.
• Daemon cleanly reaches shutdown logic in early-cancel test scenarios.
• K8s mode and non-K8s mode behave consistently.

Error Resilience

• No crash when:
  • BPF loading fails
  • NRI is disabled
  • Policy=false or HostPolicy=false
  • SystemMonitor is intentionally not created
• Clean fallback behavior without affecting other subsystems.

Memory Overhead

• Minimal — only a single map allocation when needed.
• No extra goroutines.
• No unbounded growth or high memory usage.

---

Additional information for reviewer?

• This is a pure bug fix, not tied to the containerd/NRI worker-pool improvements.
• Reproducible in clean environments with no configuration.
• Bug was blocking local development and CI validations.
• No behavioral changes. No API/interface changes. Fully backward-compatible.

---

Checklist:

• Bug fix. Fixes #
• New feature (non-breaking change which adds functionality)
• Breaking change (existing functionality impacted)
• Documentation update required
• PR Title follows <type>(<scope>): <subject>
• Commit has unit tests
• Commit has integration tests

[rksharma95]

@keshav78-78 please rebase the PR. LGTM, just one comment inline.

[rksharma95]

the reported scenario (SystemMonitor == nil) could arise when both policy and hostpolicy are disabled (by default policy is enabled), in that case systemMonitor will not be initialized and will result in panic.

this fix looks good although we can safely remove if dm.SystemMonitor != nil && dm.SystemMonitor.Logger != nil as we're early returning if any of these case is true.

[keshav78-78]

Thanks for the update — doing it in a moment. Will push the changes shortly.