Kiali v1.73 is in an invalid state for a couple of seconds after switching from MultiTenant to ClusterWide.
There is an error in the kiali operator
```
deployment.cluster_wide_access must be enabled (i.e. 'true') when all namespaces are to be accessible (e.g. deployment.accessible_namespaces is undefined or has '**'). Aborting.
```

It is because the memberroll controller sets accessible_namespaces and api.namespaces.exclude according to the SMCP mode here: https://github.com/maistra/istio-operator/blob/maistra-2.6/pkg/controller/servicemesh/memberroll/controller.go#L377-L381

When a new SMCP is created, there is no issue:

1. The Maistra operator generates the Kiali Custom Resource (CR) without cluster_wide_access set. (since it is not in kiali cr helm template)
2. The memberroll controller populates accessible_namespaces.
3. The addons.go logic then sets the cluster_wide_access field explicitly. This sequence does not cause issues.

However, a temporary invalid Kiali CR state can occur when an existing MultiTenant SMCP is updated to ClusterWide mode. In this scenario:

1.   The Kiali CR already exists with cluster_wide_access=false. (introduced by https://github.com/maistra/istio-operator/pull/1881  )
2.   When the memberroll controller updates accessible_namespaces to `*`, the Kiali CR becomes temporarily invalid from the Kiali operator's perspective. ( because contains accessible_namespaces=* as well as cluster_wide_access=false which is not allowed )
3. This invalid state persists until the addons.go logic patches the Kiali CR to set cluster_wide_access=true.

Even though this error takes only couple of seconds, it would be fine to fix it to not have misleading errors in the kiali operator log.

Proposed fix:
Every time the memberroll controller sets accessible_namespaces="", it should set explicitly also cluster_wide_access=false