Add language detection to auto-monitor to inject only the relevant SDK

[v-iw]

This supersedes #380. That PR had conflicts with main and could not be updated in place, so it has been rebased here. Original commits are preserved with @Miqueasher as author.

Only difference from #380: the go.mod / go.sum change is dropped. It bumped opencontainers/image-spec to v1.1.0-rc3, a leftover from the registry-inspection approach that commit acf4dc8 ("removing network call") already removed. main is now on v1.1.1 and nothing in the final code imports go-containerregistry, so the change was both unused and a downgrade. That was the entire source of the conflict.

The three source files are byte-identical to #380 at acf4dc8. Net diff against main is 3 files, no dependency changes.

---

Original description from #380

Carried over verbatim. Note: the "Detection Layers" item 1 (registry image config) and the "Dependencies added" table describe the first commit only. The second commit (acf4dc8, "removing network call") removed the registry lookup and the go-containerregistry dependency, so detection now relies on image name patterns, pod-spec env vars, and pod-spec commands, with fallback to all languages.

Summary

When monitorAllServices: true, auto-monitor currently injects all 4 language SDK init containers (Java, Python, Node.js, .NET) into every pod regardless of runtime, causing liveness/readiness probe failures, restart loops, and deployment instability.

This PR adds a registry-based language detector that inspects container image config (ENV, CMD, ENTRYPOINT) via google/go-containerregistry without pulling layers (~100-500ms, 5s timeout)
Falls back gracefully through image name patterns → pod-spec env vars → pod-spec commands → all languages (current behavior), ensuring zero regression

Detection Layers

1. Registry image config — fetch ENV/CMD/ENTRYPOINT from manifest (public registries + ECR with IRSA)
2. Image name patterns — match language keywords in image reference
3. Pod-spec env vars — check for JAVA_HOME, PYTHONPATH, NODE_ENV, DOTNET_ROOT, etc.
4. Pod-spec commands — match runtime binaries (java, python, node, dotnet)
5. Fallback — all configured languages

Dependencies added

Package | Version | Purpose
github.com/google/go-containerregistry | v0.20.0 | Fetch image config from registry without pulling layers
github.com/aws/aws-sdk-go (existing) | v1.45.25 | ECR auth via custom keychain

Test Plan

• Unit tests: 92/92 passing (65 new + 27 existing, zero regressions)
• Live EKS validation (us-east-1): Custom operator build deployed with monitorAllServices=true, no manual annotations
• Java, Python, Node.js, .NET public images → 1 init container each (detected via registry config)
• Alpine, Nginx, Busybox → 4 init containers (correct fallback, no false positives)
• Private ECR image with language keyword → detected via image name pattern
• Pod-spec JAVA_HOME on Alpine → detected via env var fallback
• Multi-container (Python + Nginx sidecar) → correctly detected Python only
• Failure mode: When all detection fails, behavior is identical to current production
• Operator image digest confirmed matching between running pod and ECR (sha256:5f74a89f76b3...), zero pod restarts observed

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.