Restores do not cause red health (#59015)

Since 2.0.0 (56a264cf6d80) we have documented that restoring a snapshot
typically results in `red` cluster health. However since 5.0.0 (#19516)
this hasn't been true, we report `yellow` health for unassigned
primaries that will be recovered from a snapshot in the future. This
commit adjusts these docs to match today's behaviour.

docs/reference/snapshot-restore/monitor-snapshot-restore.asciidoc

@@ -48,13 +48,14 @@ GET /_snapshot/my_backup/snapshot_1/_status
 While snapshot info method returns only basic information about the snapshot in progress, the snapshot status returns
 complete breakdown of the current state for each shard participating in the snapshot.
 
-The restore process piggybacks on the standard recovery mechanism of the Elasticsearch. As a result, standard recovery
-monitoring services can be used to monitor the state of restore. When restore operation is executed the cluster
-typically goes into `red` state. It happens because the restore operation starts with "recovering" primary shards of the
-restored indices. During this operation the primary shards become unavailable which manifests itself in the `red` cluster
-state. Once recovery of primary shards is completed Elasticsearch is switching to standard replication process that
-creates the required number of replicas at this moment cluster switches to the `yellow` state. Once all required replicas
-are created, the cluster switches to the `green` states.
+The restore process piggybacks on the standard recovery mechanism of the
+Elasticsearch. As a result, standard recovery monitoring services can be used
+to monitor the state of restore. When the restore operation is executed the
+cluster typically goes into `yellow` state because the restore operation works
+by recovering primary shards of the restored indices. Once the recovery of the
+primary shards is completed Elasticsearch switches to the standard replication
+process that creates the required number of replicas. Once all required
+replicas are created, the cluster switches to the `green` states.
 
 The cluster health operation provides only a high level status of the restore process. It's possible to get more
 detailed insight into the current state of the recovery process by using <<indices-recovery, index recovery>> and
@@ -86,4 +87,4 @@ repositories require write global metadata access. The snapshot operation requir
 well as the global metadata were readable. The restore operation requires the global metadata to be writable, however
 the index level blocks are ignored during restore because indices are essentially recreated during restore.
 Please note that a repository content is not part of the cluster and therefore cluster blocks don't affect internal
-repository operations such as listing or deleting snapshots from an already registered repository.
+repository operations such as listing or deleting snapshots from an already registered repository.