fix: deletion defects and resource orphans

[Herbaert]

Summary

Fixes six defects in the cluster and machine reconcilers where deletion could
hang and leave STACKIT resources orphaned, and where changes that should trigger
a reconcile did not. Also stops the manager from holding Secret contents in
memory.

Changes

• Deletion is no longer blocked by a missing owner. The owner lookups in
  both reconcilers moved behind the DeletionTimestamp branch. The cluster
  reconciler tolerates a deleted owning Cluster and takes its name from the
  ownerReference; the machine reconciler finalizes with a CleanupSkipped
  warning event when the Machine, Cluster or StackitCluster is gone, since
  without them there are neither credentials nor tags left to reach the server.
  Only a genuinely absent owner is tolerated — a transient API error still fails
  the reconcile rather than dropping a finalizer over a running server.
• StackitCluster keeps its finalizer and requeues while Machines for the
  cluster still exist, so those machines can still resolve credentials and delete
  their servers. Cluster API orders this correctly on its own, but a namespace
  teardown or a direct delete bypasses that ordering.
• Finalizers are persisted before the first cloud call, rather than only
  through the deferred patch at the end of Reconcile. A crash in between
  previously left a running server or load balancer behind an object carrying no
  finalizer to clean it up.
• StackitMachine deletion resolves the server by tags when
  status.instanceID is empty, instead of treating empty status as proof that no
  VM exists.
• The StackitCluster → StackitMachine watch resolves the owning Cluster
  before matching Machine.spec.clusterName, and label-selects server-side. It
  previously matched against the StackitCluster name, which breaks whenever the
  two differ — as they always do for ClusterClass-generated infrastructure refs.
• The credentials Secret is watched. A new mapper enqueues every
  StackitCluster whose credentialsSecretRef points at the changed Secret,
  searching across namespaces because that ref's namespace is optional.
  Previously, correcting an invalid Secret never re-reconciled the cluster,
  because the failure path deliberately returns without a requeue.
• Secret contents are kept out of the manager's informer cache via a
  Transform that drops Data and managed fields, with DisableFor on the
  client so the reads that need the real bytes go to the API server. No label
  selector, unlike Cluster API's own equivalent: Cluster API only watches Secrets
  it stamps itself, whereas the credentials and bastion cloud-init Secrets here
  are user-created and unlabelled, so a selector would silently disable those
  watches.
• Reconciler-internal variables renamed for readability (no behavior change);
  debug/ references dropped from test comments; the README compatibility table
  corrected from the v1beta1 to the v1beta2 contract, which is what
  metadata.yaml, the CRD labels and every import already declare.

Notes

• Breaking changes: none. No API, CRD or RBAC changes.
• Migration: none.
• Behavior/infrastructure: the manager now sets Cache and Client options, so
  every Secret read is a live API call — one per cluster reconcile, two per
  machine reconcile. CAPA and CAPG do not harden the Secret cache at all and
  therefore pay no read cost; Cluster API core hardens it and compensates with a
  second, caching client for hot reads. This provider takes the hardened side
  without that compensation, which stays bounded and event-driven at the fleet
  sizes in scope. Watching Secrets as PartialObjectMetadata against a dedicated
  metadata cache would go one step further, at the cost of a second cache in
  main.go for a small remaining gain. The new credentials watch adds reconciles
  when that Secret changes.
• Tests: an envtest regression test was added for each fix, and every one was
  verified to fail when its fix is reverted. Unit tests cover the new cache
  options. go build ./..., go test ./... and golangci-lint run ./... pass;
  make manifests produces no diff. The e2e suite was not run.

[tuunit]

how or when can these cases effectively happen? as far as i know provider machines are owned by machines which in turn are owned by a cluster and they are created in that order

Cluster -> MachineDeployment -> Machine -> ProviderMachine

[Herbaert]

Reverted