Make DefaultSidecarImage operator-configurable via env var instead of compile-time constant

[bdchatham]

Problem

DefaultSidecarImage at internal/platform/platform.go:8 is a compile-time constant. Bumping the default sidecar image (e.g. when the sei-config schema gains a new field that the sidecar's vendored sei-config doesn't yet recognize) requires:

1. Editing the constant in source.
2. Cutting a controller PR + merge.
3. Rebuilding the controller container image via CI.
4. Bumping the controller image in the cluster manifest.
5. Rolling out the new controller pod.

That's 4 layers of release cadence tied together for what's fundamentally a single config value. It also tightly couples the controller's release cycle to the sidecar's, which slows down sidecar version bumps that should be cheap.

Impact

Most recently surfaced when the harbor nightly release-test orchestrator needed evm.enabled_legacy_sei_apis overrides — the sidecar built against sei-config v0.0.13 rejected the override key, requiring the constant bump in #204 (sei-k8s-controller). That whole flow could have been a single Flux manifest update if the constant were an env var instead.

Future situations where this matters:

• New sei-config schema fields where the sidecar must catch up.
• Operator-side seictl security patches that don't touch the controller binary.
• Per-cluster sidecar versioning (test clusters running a newer/older sidecar than prod for validation).

Relevant experts

• kubernetes-specialist — owns the controller's environment / config-handling pattern.
• platform-engineer — owns the manifest layout that operators use.

Proposed approach

Add a new env var SEI_DEFAULT_SIDECAR_IMAGE read at controller startup. Wire it into the existing platform.Config struct in internal/platform/platform.go alongside the other SEI_* config fields (SEI_NODEPOOL_NAME, SEI_TOLERATION_KEY, etc.).

// platform.Config (existing struct)
type Config struct {
    // ... existing fields ...
    DefaultSidecarImage string  // SEI_DEFAULT_SIDECAR_IMAGE
}

sidecarImage(node) at internal/noderesource/noderesource.go:285 consumes Config.DefaultSidecarImage instead of the package-level constant. The constant platform.DefaultSidecarImage becomes the fallback only if the env var is unset (preserves backward compatibility for tests, local dev, and any deployment that hasn't set the env var yet).

Architectural constraints

• The constant must remain as a fallback — operators who haven't set the env var get the same behavior as before.
• The env var should be required in Config.Validate() once the operator-facing manifest is updated to set it. Stage this as a non-breaking change first (constant fallback), then promote to required in a follow-up once all consumers are updated.
• Existing per-SND override path (spec.template.spec.sidecar.image) wins over the env var, just like it currently wins over the constant. No change to sidecarImage() precedence ordering.

Acceptance criteria

• Config.DefaultSidecarImage field added; reads from SEI_DEFAULT_SIDECAR_IMAGE env var.
• sidecarImage(node) reads Config.DefaultSidecarImage instead of the package-level constant.
• Constant remains as fallback; env-var-unset path is identical to today.
• Manifest in manifests/manager.yaml (or equivalent) sets the env var.
• Test that env-var override flows through to sidecarImage().

Out of scope

• Removing the package-level constant entirely (keep as fallback for now).
• Per-SeiNode-mode sidecar images (e.g., archive nodes get a different sidecar). If needed, separate issue.
• Configuring the sidecar's bootstrap image via env var (the init sidecar, if different).

References

• Compile-time site: internal/platform/platform.go:8.
• Consumer: internal/noderesource/noderesource.go:285-290 (sidecarImage function).
• Recent bump that motivated this: chore(platform): bump DefaultSidecarImage to seictl built against sei-config v0.0.14 #204.
• Existing env-var pattern in Config.Validate(): internal/platform/platform.go:60-93.