Dynamic SET GLOBAL wsrep_cluster_address='gcomm://' leaves wsrep_new_cluster stuck, so a later real address bootstraps instead of joining

When `wsrep_cluster_address` is changed at runtime to `gcomm://`, `wsrep_start_replication()`
auto-detects the bootstrap case and sets the process-global `wsrep_new_cluster = true`. That flag
is reset only on the startup path (after `wsrep_init_startup()`); neither the dynamic update hook
nor `wsrep_stop_replication()` clears it. A later dynamic change of `wsrep_cluster_address` to a
real address therefore still passes `bootstrap=true` to the provider and starts a new cluster
instead of joining the configured cluster.

Steps to reproduce (single node, official image)

```bash
docker run -d --name mdev58 \
--env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=yes \
mariadb@sha256:dd9b303aed4f4890ed09f766d8ca9ddfd176c0c6f6267feff53b3192ec65a979 \
--wsrep-on=ON --wsrep-provider=/usr/lib/libgalera_smm.so \
--wsrep-cluster-address=gcomm:// --wsrep-cluster-name=dsh58 \
--wsrep-node-address=127.0.0.1:4567 --wsrep-sst-receive-address=127.0.0.1:4444

1. wait until ready, then:
   docker exec mdev58 mariadb -uroot -e "SET GLOBAL wsrep_cluster_address='gcomm://';"
   docker exec mdev58 mariadb -uroot -e "SET GLOBAL wsrep_cluster_address='gcomm://127.0.0.1:19999';"
   docker exec mdev58 mariadb -uroot -e "SHOW STATUS LIKE 'wsrep_cluster_status'; SHOW STATUS LIKE 'wsrep_ready';"
   ```

Fault case (after the `gcomm://` step): `wsrep_cluster_status=Primary`, `wsrep_ready=ON` even
though the configured address points to an unreachable peer.

Control case (same server, no prior dynamic `gcomm://` step): setting the same unreachable
address produces `wsrep_cluster_status=Disconnected`, `wsrep_ready=OFF`, i.e. the server tries to
join and fails — the expected behaviour.

1. 1. Expected result

After the address no longer contains the auto-bootstrap marker, the next dynamic reconfiguration
should attempt to join the configured cluster (or fail as Disconnected), not bootstrap again.