fix(eks-v2): respect securityGroup(s) in KubectlProviderOptions

[letsgomeow]

Issue # (if applicable)

Closes #36653.

Reason for this change

When specifying a securityGroup in KubectlProviderOptions, the
value was being ignored. The cluster's security group was always
applied to the kubectl handler (Lambda) instead of the user-specified
one.

The root cause was twofold:

1. cluster.ts was not passing securityGroup through to the
   KubectlProvider constructor
2. kubectl-provider.ts always fell back to
   props.cluster.clusterSecurityGroup regardless of whether
   props.securityGroup was set

Description of changes

kubectl-provider.ts

• Fixed the security group resolution logic with the following
  priority order:
  1. securityGroups (new array property) — highest priority
  2. securityGroup (existing single property) — backwards compatible fallback
  3. clusterSecurityGroup — default (preserves existing behavior)
• Added new securityGroups?: ec2.ISecurityGroup[] property to
  KubectlProviderOptions to support specifying multiple security
  groups (consistent with lambda.Function which accepts an array)
• Emits a warning via Annotations.of(this).addWarningV2 when both
  securityGroup and securityGroups are specified simultaneously

cluster.ts

• Pass securityGroup and securityGroups from
  _kubectlProviderOptions to the KubectlProvider constructor

Question for maintainers:
securityGroup and securityGroups use ec2.ISecurityGroup rather
than ec2.ISecurityGroupRef, which triggers an awslint warning
suppressed with [disable-awslint:prefer-ref-interface].
The reason is that the underlying lambda.Function expects
ISecurityGroup[], so converting from ISecurityGroupRef would add
unnecessary complexity. The existing securityGroup property also
uses ISecurityGroup for consistency.
Is this approach acceptable, or would you prefer a different solution?

Describe any new or updated permissions being added

No new IAM permissions are required.

Description of how you validated changes

• Added 5 unit tests in cluster.test.ts covering:
  • securityGroups only (multiple security groups applied correctly)
  • securityGroup only (backwards compatibility)
  • Both specified (warning issued, securityGroups takes priority)
  • Neither specified (default clusterSecurityGroup used — existing behavior preserved)
  • Empty securityGroups array treated as unspecified
• Added an integration test
  (integ.eks-kubectl-security-groups.ts) with a single stack
  containing one VPC and three EKS clusters, each demonstrating a
  different security group configuration

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results	48 ran	48 passed

Test	Result
No test annotations available

• View Security Guardian Results

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results with resolved templates	48 ran	48 passed

Test	Result
No test annotations available

• View Security Guardian Results with resolved templates