feat: make sidecar container image configurable to fix forked repository deployments

[allthatjazzleo]

Problem

When forked repositories create custom images with tags like v0.25.1-test, the sidecar containers (healthcheck, version-check-interval, and version-check) still try to fetch the hardcoded image ghcr.io/strangelove-ventures/cosmos-operator:v0.25.1-test, which doesn't exist in the upstream registry. This causes deployment failures for forked repositories.

Solution

Refactored image retrieval in pod builder to use a new version.Image() method instead of hardcoded image references, enabling forked repositories to override the container image via build-time ldflags.

Changes Made

• Added new version.Image() method in internal/version/version.go that returns configurable image name
• Updated pod builder (internal/fullnode/pod_builder.go) to use version.Image() instead of hardcoded ghcr.io/strangelove-ventures/cosmos-operator
• Enhanced Docker build process to accept IMG build argument and pass it via ldflags
• Fixed GitHub Actions workflow to properly handle lowercase image names and pass image name as build argument

Benefits

• Fixes deployment issues for forked repositories using custom image registries
• Maintains backward compatibility - defaults to original image if not overridden
• Enables proper testing for downstream consumers with custom images
• Follows existing build-time configuration pattern similar to version handling

Usage for Forked Repositories

Forked repositories can now set their custom image during build:

go build -ldflags "-X github.com/strangelove-ventures/cosmos-operator/internal/version.image=ghcr.io/my-fork/cosmos-operator"