Chart only supports a single trust group/rule, blocking CAC for multi-tenant trust scopes

Problem

console.trustedImages in chart/values.yaml supports configuring exactly one trust group and one rule, both sharing the same name (trustedImages.name). This is fine for simple deployments but forces consumers with multiple thematic trust scopes to either:

1. Collapse all registry patterns into one fat group, losing per-scope organization (audit logs read "trusted by <one-group-name>" for every image, regardless of whether it's an ironbank pull, a tenant registry, or an EKS control-plane component).
2. Manage extra groups manually via the Twistlock API, drifting from CAC.

Real-world deployment patterns

Across multiple BB-managed Twistlock consoles in production, the actual trust policy uses 3-5 distinct groups per console (e.g. one for ironbank, one for AWS EKS control-plane images, one or more for tenant registries, one for opt-in test images). Concrete distribution observed across the enterprise:

Environment	Distinct groups in use
P1ES Production	4
IronBank IL2	4
IronBank IL5	4
PartyBus IL2	3
PartyBus IL4	3
PartyBus IL5	3

None of these can be expressed in upstream chart values today; operators either take Path 1 above (one fat group) and lose audit fidelity, or run Path 2 (manual API management) outside of CAC.

Related limitation: overlay-driven layering

Even after a list shape lands, consumers that layer values on top of the chart (kustomize SMP on a HelmRelease, subchart values, Argo CD valueFiles stacks) cannot append entries without redeclaring the entire base list, because Helm and kustomize both replace lists on merge rather than appending. Concretely, a PartyBus deployment with a shared base set of EKS / IronBank groups across IL2/IL4/IL5 plus per-environment additions is forced to copy-paste the base set into each leaf overlay.

Proposal

Add console.trustedImages.groups (list) and console.trustedImages.rule (single object) to declare multiple groups bound to one chart-managed rule. Add console.trustedImages.extraGroups, concatenated with groups at template time, so overlays can append entries under a separate map key without replacing the base list (matches the Bitnami extraEnvVars / extraVolumes convention). Replace the single-group fields (name, registryMatches, defaultEffect) with the new shape; default the new fields to produce the same Twistlock state as before (one BigBang-Trusted group covering ironbank with effect=alert) so chart-default consumers see no behavioral change.

This is the minimum change to unblock CAC for the existing patterns and to support overlay-driven layering downstream.