fix(nexus): tighten config validation and skip empty pod annotations

[fank]

Summary

Follow-up on review feedback from #14:

• Skip empty annotations: block. The deployment template emitted an empty annotations: key whenever the provider wasn't configMap and podAnnotations was empty. The block is now gated on actually having something to write.
• Checksum the SecretProviderClass too when create: true, so edits to the chart-managed SPC roll the pod the same way ConfigMap edits do.
• Tighten nexus.validateConfigProvider:
  • config.mountPath is required whenever config.provider is set.
  • secretProviderClass requires driver.
  • secretProviderClass.create: true additionally requires provider and a non-empty secrets list (otherwise the SPC would render incomplete and apply would fail with a less clear error).

Chart version: 0.5.0 → 0.5.1.

Test plan

• provider: "" (default) — no annotations: block in the deployment
• provider: secretProviderClass with create: false — no annotations: block
• provider: configMap — checksum/config annotation present
• provider: secretProviderClass with create: true — checksum/config annotation present (hashing the SPC)
• mountPath: "" with provider set — fail "config.mountPath is required when config.provider is set"
• SPC with empty driver — fail with required-field message
• SPC with create: true but missing provider — fail
• SPC with create: true but empty secrets — fail
• helm lint clean

[gemini-code-assist]

Code Review

This pull request bumps the Nexus chart version to 0.5.1 and introduces enhanced validation for configuration providers in the helper templates, ensuring that mount paths and SecretProviderClass details are correctly defined. Additionally, it updates the deployment template to include a configuration checksum for SecretProviderClass to trigger pod restarts on changes. A review comment identifies a potential issue where the 'checksum/config' annotation key could collide if users provide the same key in custom pod annotations or if multiple providers are used.

[gemini-code-assist]

The checksum/config annotation is used for both configMap and secretProviderClass providers. While they are currently mutually exclusive, if the chart were extended to support multiple providers simultaneously, this would lead to duplicate keys in the YAML. Additionally, if a user provides checksum/config in podAnnotations, it will be duplicated or overwritten depending on the YAML parser. Consider using a more unique key or merging the annotations to avoid potential collisions.