fix: Update api group naming to retina.sh

[kamilprz]

Description

There was still mentions of retina.io within the cluster role files for agent and operator. This PR updates those to retina.sh.

Related Issue

#1936

Checklist

• I have read the contributing documentation.
• I signed and signed-off the commits (git commit -S -s ...). See this documentation on signing commits.
• I have correctly attributed the author(s) of the code.
• I have tested the changes locally.
• I have followed the project's style guidelines.
• I have updated the documentation, if necessary.
• I have added tests, if applicable.

Screenshots (if applicable) or Testing Completed

Applying changes to helm chart shows that cluster role is now retina.sh

>make helm-install-hubble
helm upgrade --install retina ./deploy/hubble/manifests/controller/helm/retina/ \
        --namespace kube-system \
        --set os.windows=true \
        --set operator.enabled=true \
        --set operator.repository=ghcr.io/kamilprz/retina/retina-operator \
        --set operator.tag=v0.0.33-dev-rc1 \
        --set agent.enabled=true \
        --set agent.repository=ghcr.io/kamilprz/retina/retina-agent \
        --set agent.tag=v0.0.33-dev-rc1 \
        --set agent.init.enabled=true \
        --set agent.init.repository=ghcr.io/kamilprz/retina/retina-init \
        --set agent.init.tag=v0.0.33-dev-rc1 \
        --set logLevel=info \
        --set hubble.tls.enabled=true \
        --set hubble.relay.tls.server.enabled=true \
        --set hubble.tls.auto.enabled=true \
        --set hubble.tls.auto.method=cronJob \
        --set hubble.tls.auto.certValidityDuration=1 \
        --set hubble.tls.auto.schedule="*/10 * * * *"
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /mnt/c/Users/kamilp/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /mnt/c/Users/kamilp/.kube/config
Release "retina" has been upgraded. Happy Helming!
NAME: retina
LAST DEPLOYED: Mon Dec  8 13:35:46 2025
NAMESPACE: kube-system
STATUS: deployed
REVISION: 2
TEST SUITE: None
>
>
>
>kubectl get clusterrole retina-cluster-reader -o yaml | grep "retina."
  name: retina-cluster-reader
  - retina.sh
  - retinaendpoints
  - retina.sh
  - retinaendpoints
  - retina.sh
  - retina.sh
  - retinaendpoints/finalizers
  - retina.sh
  - retinaendpoints/status
>
>
>
>kubectl get clusterrole retina-operator-role -o yaml | grep "retina."
  name: retina-operator-role
  - retina.sh
  - retina.sh
  - retina.sh
~/src/retina kamilp/helm-roles
>

Listing captures

>kubectl get captures.retina.sh -A
NAMESPACE   NAME            AGE
default     test-capture    122m
default     test-capture2   117m

With retina.io apigroup

>kubectl auth can-i list captures.retina.sh --as=system:serviceaccount:kube-system:retina-operator -A
no

With retina.sh apigroup

>kubectl auth can-i list captures.retina.sh --as=system:serviceaccount:kube-system:retina-operator -A
yes

The retina agent will still return no, as it doesn't have the captures resources defined in its clusterrole.