fix: reject resourceNames and nonResourceURLs in rbac.rules

What does this MR do?

A rule in rbac.rules that sets resourceNames, for example get on one secret, renders without the names, so the Role grants get on every secret in the namespace. A rule with only nonResourceURLs renders as the same verbs on every core resource. The chart copies only apiGroups, resources and verbs from each rule and drops other keys without a message.

This MR fails the render when a rule sets either key, and the message names the rule and the key. Values that set them now fail on install or upgrade instead of creating a wider Role. Other rules render byte for byte as before.

flowchart TD
  R["rbac.rules entry in templates/role.yaml"] --> K{"sets resourceNames<br/>or nonResourceURLs?"}
  K -- no --> O["rule renders from apiGroups, resources, verbs"]
  K -- "yes, before" --> D["key dropped, rule renders without it"]
  K -- "yes, after" --> F["helm template fails with the rule index and key"]
  style D stroke-dasharray: 5 5

Why was this MR needed?

@lachie-gitlab suggested rejecting these keys in gitlab-org/gitlab-runner!7629 (comment 4017373286). This is the chart's first fail.

What's the best way to test this MR?

helm unittest .
helm template r . --set gitlabUrl=https://gitlab.example.com --set runnerToken=dummy --set rbac.create=true --set "rbac.rules[0].resources[0]=secrets" --set "rbac.rules[0].verbs[0]=get" --set "rbac.rules[0].resourceNames[0]=only-this-secret" --show-only templates/role.yaml

The render fails and names rbac.rules[0] and resourceNames. On main it prints the rule without the names, and on a k3s cluster chart 0.93.0 let the runner service account get secrets/other-secret.

What are the relevant issue numbers?

gitlab-org/gitlab-runner!7629 documents the default Role the chart creates.

An AI coding assistant wrote this change. It ran helm unittest . and helm lint . with Helm 3.7.2 and 4.3.0, and the cluster check above on a test VM.