feat: patch CR status via the Kubernetes client, not kubectl

[haseebsyed12]

A hook process handles every CR in one binding context, and each status
write forked kubectl: process spawn, kubeconfig load and API discovery per
resource. With a few dozen CRs that is tens of seconds of pure overhead per
reconcile. One CustomObjectsApi, configured once, replaces it.

It also makes failures diagnosable. The chart derives the /status
RBAC rule from the CRD, so a template miss surfaces as a 403 -- previously
an opaque stderr string, now an HTTP status in the log. The error body is
truncated so one apiserver Status object cannot flood a log line.

The request on the wire is unchanged: the client's default content type for
this method is application/merge-patch+json, the same as
kubectl patch --type merge --subresource status.

group, version and plural are derived from the two environment values the
chart already injects, so no new configuration. kubernetes>=32.0.0 was
already a dependency and utils.py already loaded client config; that load
is extracted as load_kubernetes_config and shared.

A namespace is now required to address the object rather than falling back
to kubectl's context namespace. All three plugin CRDs are Namespaced and the
namespace comes from the CR or POD_NAMESPACE, so this is unreachable in
practice; it is a warning-and-skip rather than a silent misdirected patch.

What does this change do?

Upgrade impact

• This change requires operator action to upgrade. If checked, add the
  upgrade-impact label and a release note: run scriv create from the
  repository root and describe the required action in the generated
  changelog.d/ file. See RELEASING.md.

Operator action means anything a deployment has to do beyond a normal resync:
deploy repo or values changes, new or removed secrets, enabling or disabling a
component, or a manual one-time step.