Allow running CRD conversion webhook server without controllers

### What would you like to be added (User Story)?

As an operator, I would like to be able to manipulate cluster-api objects in certain situations without having them immediately reconciled by the `capi-controller-manager`

### Detailed Description

Today, the conversion webhooks are nested with the `capi-controller-manager`. This proves problematic in scenarios where the management cluster is being restored from an object-level backup, using a tool like https://github.com/rancher/backup-restore-operator or https://velero.io/ as the conversion webhook on the CRD will fail if the webhook endpoint is not available.

During these restoration operations, it is desirable to be able to run the conversion webhook server while "paving" the objects into place, but not having immediate reconciliation actions take place on them until the restoration is complete. I am thinking for example, the case where a `MachineSet` has child `Machines` and if the `MachineSet` object is restored while controllers are running, it could spawn new `Machine` objects that have not yet been restored.

There are a few workarounds to this, namely:
* Annotate all cluster-api objects with `cluster.x-k8s.io/paused=true`
* Set a bogus watch filter value
* Set the concurrency for all of the controllers to `0` (not tested but theoretically this works?)

but all of them are less than ideal solutions for a "robust" DR strategy.

### Anything else you would like to add?

_No response_

### Label(s) to be applied

/kind feature
/area provider/core

Start by tracing how the conversion webhooks are nested with the capi-controller-manager and how CRDs reach that webhook endpoint. Compare the desired restore flow with controller startup and reconciliation behavior, including the listed pause, watch-filter, and concurrency workarounds. Done means the conversion webhook can run while reconciliation is deliberately withheld during restoration.

Written by the indexing model from the issue text.