refactor(operator): introduce ClusterUser to make actor-vs-SUT boundary explicit

[SamBarker]

Type of change

• Refactoring

Description

Introduces ClusterUser — a thin wrapper around a KubernetesClient scoped to the test namespace — to give integration tests an explicit, named object representing the actor (a regular Kubernetes user), distinct from the operator (the system under test).

Previously, LocalKroxyliciousOperatorExtension exposed create, get, replace, delete, and resources methods that silently delegated to an internal TestActor. This made test code look like the operator itself was creating resources, obscuring the actor/SUT boundary.

Changes:

• ClusterUser: new class with create, get, replace, delete, resources — backed by the admin Kubernetes client scoped to the test namespace
• LocallyRunningOperatorRbacHandler.userClient(): exposes the lazily-created admin client for constructing a ClusterUser
• LocalKroxyliciousOperatorExtension.clusterUser(): returns a ClusterUser scoped to the test namespace; must be called after beforeAll
• All seven ReconcilerIT files migrated to obtain a ClusterUser via operator.clusterUser() and route resource operations through it
• LocalKroxyliciousOperatorExtension.create/get/replace/delete/resources removed — they are now dead code
• patchStatus remains on the extension: it represents test infrastructure simulating another system updating status subresources, not a user action

AllReconcilersIT also updates its parameterised-test lambdas from Function<LocalKroxyliciousOperatorExtension, T> to Function<ClusterUser, T> since those lambdas create user-side resources (Secrets, ConfigMaps).

Additional Context

This is a follow-on to refactor/operator-it-shared-resources (the base branch). The ClusterUser name was chosen deliberately — it communicates a Kubernetes user perspective without overloading the term "user". A future clusterUser(ClusterRole) overload could enable RBAC-persona testing (platform team vs. app team) when needed.

Checklist

• PR raised from a fork of this repository and made from a branch rather than main.
• Write tests
• Update documentation
• Make sure all unit/integration tests pass
• Make sure all Sonarcloud warnings are addressed or are justifiably ignored.
• If applicable to the change, make sure system tests pass.
• If applicable to the change, trigger the performance test suite.
• Ensure the PR references relevant issue(s) so they are closed on merging.
• For user facing changes, update CHANGELOG.md