Feature: Stale controller mitigation

Tasks:
* [x] Implement stale controller mitigation util in reconcile wrapper: https://github.com/kubernetes-sigs/cluster-api/pull/13720
* [x] Implement stale controller mitigation in MD controller: https://github.com/kubernetes-sigs/cluster-api/pull/13720
* [x] Extend stale controller mitigation in MD controller to MS deletion https://github.com/kubernetes-sigs/cluster-api/pull/13730
* [x] Implement stale controller mitigation in KCP / MS / Cluster topology controller: https://github.com/kubernetes-sigs/cluster-api/pull/13737
* [x] Refactor consistency store to allow defer without previous store registration https://github.com/kubernetes-sigs/cluster-api/pull/13751

Backlog (all TBD)
* [ ] Defer Reconciles if reconciled object was written in a previous reconcile https://github.com/kubernetes-sigs/cluster-api/issues/10911 (maybe also for other objects that we write in Reconcile)
* [ ] Audit all other controllers to avoid unnecessary Reconciles with a stale cache (as we have to re-reconcile later anyway when the cache is up-to-date). For example the Cluster topology controller might want to wait until the cache sees all the objects that the Reconcile has written (InfraCluster, CP, MD, MHC, ...)
* [ ] Consider deferring after status writes of the reconciled object (defer patchHelper.Patch). Some notes:
* patchHelper does not return the resulting RV today (maybe add an additional method to retrieve the RV, like we have for SSA patch helper?)
* we should only defer next reconcile if the patchHelper actually patched (i.e. the RV is changed)
* [ ] [TBD] Think about if we can use this feature to replace cluster-shim & best-effort cleanup of leaked referenced objects (e.g. InfraMachineTemplate if MD creation fails) in the Cluster topology controller (and maybe also in other controllers (KCP/MS))

Prior art:
* https://kubernetes.io/blog/2026/04/28/kubernetes-v1-36-staleness-mitigation-for-controllers/
* https://github.com/kubernetes/kubernetes/pull/137212