Three interrelated issues here:

- [ ] `TransportBroadcastByNodeAction` derivatives are typically executed via `NodeClient` which bypasses the `TransportService` and therefore does not respect (or even know about) the `executor` parameter which would fork. This means that the coordination work, including grouping all the shards by node, happens on the calling thread. When executed from the REST layer, that's a transport worker. This is #97916, but until that's fixed we need a workaround.

- [ ] The node-level responses are deserialised and processed on the receiving transport worker too.

- [ ] Several of these actions use `SAME` for their executor, bypassing the forking that _does_ exist today.

Relates #77466 
server/src/main/java/org/elasticsearch/action/admin/indices/stats/TransportFieldUsageAction.java
import org.elasticsearch.common.inject.Inject;
import org.elasticsearch.common.io.stream.StreamInput;
import org.elasticsearch.index.shard.IndexShard;
import org.elasticsearch.index.shard.ShardId;
import org.elasticsearch.indices.IndicesService;
import org.elasticsearch.tasks.Task;
import org.elasticsearch.threadpool.ThreadPool;
import org.elasticsearch.transport.TransportService;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class TransportFieldUsageAction extends TransportBroadcastByNodeAction<
    FieldUsageStatsRequest,
    FieldUsageStatsResponse,
    FieldUsageShardResponse> {
    private final IndicesService indicesService;
    @Inject
    public TransportFieldUsageAction(
        ClusterService clusterService,
        TransportService transportService,
        IndicesService indexServices,
        ActionFilters actionFilters,
        IndexNameExpressionResolver indexNameExpressionResolver
    ) {
        super(
            FieldUsageStatsAction.NAME,
            clusterService,
            transportService,