Same queries, different servers, different exec plans, stats are up to date
In the slow plan, the plan sub-tree that contains all the remote queries is executed 2928 times.  It would have been 3632 times (the number of rows on the outer input to the nested loops join that has the remote query sub-tree on its inner side), but the Distinct Sort is able to rewind (reuse) the prior iteration's results on a number of occasions.

In the fast plan, the join is a hash join rather than nested loops, so the problematic sub-tree is only executed once.  As usual, the cause is likely the small differences in cardinality estimation (visible in the plan as estimated row counts) and derived histograms and distribution statistics (not so visible).  This variation is probably due to slightly different samples taken to build statistics, or statistics built at different times between dev and test.

To quickly validate this, you could add OPTION (HASH JOIN) to the query.  There is a small risk that the optimizer will complain that it cannot produce a plan with that hint.  I haven't analysed the plan deeply enough to predict that, and this suggestion is just for demonstration purposes.  It is not my suggested solution.

A better fix is to break the query into sections.  Refactor the remote query sub-tree processing into a separate query, and store the 6737 rows it produces in a temporary table.  You will probably want to use a #temporary table rather than a table variable, since you will get auto-generated statistics, and you will have a wider range of indexing possibilities, should that prove to be useful.

Queries with many joins and remote queries have a very large number of possible arrangements.  By breaking the query up sensibly, and providing statistics (and perhaps indexes) you are giving the optimizer better information and a smaller search space to explore.  Your chances of a good plan go up commensurately.