Update email claim example to use list of claim values

[hamza3202]

All pull requests must reference an existing issue with no blocking labels.
PRs that do not meet this requirement will be automatically closed. See the
Contributor Guide for details.

Issue Reference

Closes #6325

Description

Fix example for service account claim annotation

Checklist

• The PR is linked to an existing issue.
• [ x The linked issue has no blocking labels (kind/proposal,
  needs discussion, needs research, maintainer only, area/security,
  size/large, size/x-large, size/xx-large).
• I have added or updated tests as appropriate.
• I have added or updated documentation as appropriate.

AI Use Disclosure

Select one:

• This PR was written by a human without AI assistance.
• This PR was written by a human with AI assistance. A human has reviewed every line prior to opening the PR.
• This PR was written by an AI with human supervision. A human has reviewed every line prior to opening the PR.
• This PR was written entirely by AI. No human has reviewed this prior to opening the PR.

Sign-Off

• All commits are signed off (git commit -s) (required)
• All commits are cryptographically signed (git commit -S) (encouraged)

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	18dd7af
🔍 Latest deploy log	https://app.netlify.com/projects/docs-kargo-io/deploys/6a0ef275aa1c2800085d93de
😎 Deploy Preview	https://deploy-preview-6326.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[krancour]

Are you assuming this is a mistake in the docs? Or did you try this and it didn't work?

I don't have the code in front of me at the moment, but I am about 99% certain that all claims can be mapped to a list of string values or a scalar string value.

[hamza3202]

I was misled by the comment here and the docs here

Looking at the actual implementation, it does seem to support both string and slice of strings as values.

[krancour]

I agree that in both those locations, the description is narrower than what is supported in reality. I would welcome those being amended appropriately.

As to the change that's already proposed by this PR, as long as those overly narrow descriptions cited above are corrected, I think there would be a small benefit to leaving the example as it had been previously, since it demonstrates a broader range of supported options.