### Elasticsearch Version

8.8.1+ but probably all versions

### Installed Plugins

_No response_

### Java Version

_bundled_

### OS Version

cloud

### Problem Description

This is a follow-up of [#97370](https://github.com/elastic/elasticsearch/issues/97370). 

In a case where disk spaces are reaching limits, if ILM suddenly tries to move a lot of hot shards to cold/frozen shards, it can tip the cluster health to RED because a lot of cold/frozen shards may be created and stay unassigned as long as there is not enough disk space. However, this is not a suitable indicator for service unavailability, since the data is still safely in the respective hot shards that are becoming cold/frozen, and will remain there until the cold/frozen shards are assigned so that searches can still search them.

Thus the [Health Report API](https://www.elastic.co/guide/en/elasticsearch/reference/8.8/health-api.html) should not return RED for unassigned cold/frozen shards of ILM moves.

### Steps to Reproduce

In a case where disk spaces are reaching limits, if ILM suddenly tries to move a lot of hot shards to cold/frozen shards, it can tip the cluster health to RED because a lot of cold/frozen shards may be created and stay unassigned (as long as there is not enough disk space).

### Logs (if relevant)

_No response_
server/src/main/java/org/elasticsearch/cluster/routing/allocation/ShardsAvailabilityHealthIndicatorService.java
impacts.add(
                    new HealthIndicatorImpact(
                        NAME,
                        PRIMARY_UNASSIGNED_IMPACT_ID,
                        1,
                        impactDescription,
                        List.of(ImpactArea.INGEST, ImpactArea.SEARCH)
                    )
                );
            }
            /*
             * It is possible that we're working with an intermediate cluster state, and that for an index we have no primary but a replica
             * that is reported as unavailable. That replica is likely being promoted to primary. The only impact that matters at this
             * point is the one above, which has already been reported for this index.
             */
            Set<String> indicesWithUnavailableReplicasOnly = new HashSet<>(replicas.indicesWithUnavailableShards);
            indicesWithUnavailableReplicasOnly.removeAll(primaries.indicesWithUnavailableShards);
            if (indicesWithUnavailableReplicasOnly.isEmpty() == false) {
                String impactDescription = String.format(
                    Locale.ROOT,
                    "Searches might be slower than usual. Fewer redundant copies of the data exist on %d %s [%s].",
                    indicesWithUnavailableReplicasOnly.size(),
                    indicesWithUnavailableReplicasOnly.size() == 1 ? "index" : "indices",
                    getTruncatedIndices(indicesWithUnavailableReplicasOnly, clusterMetadata)
                );
                impacts.add(
                    new HealthIndicatorImpact(NAME, REPLICA_UNASSIGNED_IMPACT_ID, 2, impactDescription, List.of(ImpactArea.SEARCH))
                );
            }
            return impacts;