fix(k8s): honor scope-configurations image pull secrets over the values.yaml default

[pmunoz-null]

Summary

• k8s/deployment/build_context resolved image pull secrets from values.yaml before the scope-configurations provider. Because k8s/values.yaml always ships IMAGE_PULL_SECRETS (ENABLED: true, SECRETS: [ecr-secret]), the provider branch was unreachable: the security.image_pull_secrets_enabled / security.image_pull_secrets properties documented in k8s/README.md had no effect.
• Any non-EKS cluster (e.g. AKS pulling from ACR) therefore rendered pods with imagePullSecrets: [ecr-secret], a secret that does not exist there → FailedToRetrieveImagePullSecret → anonymous pull → 401 → ImagePullBackOff, until node-level registry credentials eventually let the pull through. Deployments succeeded late (tens of seconds to minutes) and with a misleading failure block in the logs.
• The block is extracted into resolve_image_pull_secrets() with this priority:
  1. PULL_SECRETS env var (unchanged)
  2. provider, only when it explicitly sets image_pull_secrets_enabled
  3. values.yaml IMAGE_PULL_SECRETS — unchanged behaviour for every install that does not set the provider property
  4. disabled

Backwards compatible: nothing changes for clusters that don't set the provider property; EKS installs relying on the shipped ecr-secret default keep working. Deliberately does not touch k8s/values.yaml — removing the default there would strip imagePullSecrets from those installs.

Why get_config_value isn't used for the flag

It evaluates <path> // empty, and jq's // treats false as empty, so an explicit image_pull_secrets_enabled: false from the provider would read as "not set". The flag is read with an explicit null-check instead; the secrets list still goes through get_config_value.

Tests

The previous test (image pull secrets: PULL_SECRETS takes precedence…) asserted on an inline copy of the if/else, so it could not catch this. It is replaced by five tests that exercise the real function (extracted via the same sed pattern used for validate_status):

• PULL_SECRETS env wins over provider and default
• provider wins over the values.yaml default (red before this change)
• provider can explicitly disable pull secrets (red before this change)
• falls back to the values.yaml default when the provider is silent
• disabled when neither provider nor default is set

bats k8s/deployment/tests/build_context.bats → 82 ok, 0 failed. Full k8s/deployment/tests → 316 ok; the 5 failures in build_deployment.bats / grpc_port_shape.bats are pre-existing on beta (they need gomplate, exit 127 in my environment) and unrelated.

Changelog

One-liner added under ## [Unreleased] (v1.16.3 is already tagged).

Not in this PR

• Making the shipped default flavor-aware (K8S_FLAVOR is eks by default; aks/aro/gke should not inherit an ECR secret name). That changes behaviour for non-EKS installs and deserves its own PR/discussion.