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/forcemerge/TransportForceMergeAction.java
ForceMergeAction.NAME,
            clusterService,
            transportService,
            actionFilters,
            indexNameExpressionResolver,
            ForceMergeRequest::new,
            ThreadPool.Names.SAME
        );
        this.indicesService = indicesService;
        this.threadPool = transportService.getThreadPool();
    }
    @Override
    protected EmptyResult readShardResult(StreamInput in) throws IOException {
        return EmptyResult.INSTANCE;
    }
    @Override
    protected ResponseFactory<ForceMergeResponse, EmptyResult> getResponseFactory(ForceMergeRequest request, ClusterState clusterState) {
        return (totalShards, successfulShards, failedShards, responses, shardFailures) -> new ForceMergeResponse(
            totalShards,
            successfulShards,
            failedShards,
            shardFailures
        );
    }
    @Override
    protected ForceMergeRequest readRequestFrom(StreamInput in) throws IOException {
        return new ForceMergeRequest(in);
    }
    @Override
    protected void shardOperation(