That last detail you added is the important one, more than the "field not found" was: more rows loading than were there to begin with. That's not a refresh ordering problem, that's the merge, and it explains why it never finishes.
A merge is a join. If the key you're matching on isn't unique in the right-hand table, every row on the left comes back once per match, so two duplicates on the right doubles it, three triples it, and the row counter runs off past your source count. Nothing errors, it just grows, which is why it presents as a refresh that hangs rather than one that fails.
Two minutes to confirm it: take the right-hand query, Group By on the join key with a Count, then filter to Count greater than 1. Or just Keep Duplicates on that column. If anything at all comes back, that's your cause. The fix is to get the right side down to one row per key before the merge, with a Group By or Remove Duplicates on the key. And if the multiplication is actually intended, use the aggregate option in the expand step instead of expanding to rows.
Worth checking the key's data type on both sides at the same time, because that's the other half of what you're describing. Microsoft's own note on merging is that the columns have to be the same data type or the merge "might not yield correct results", and a type mismatch gives you the opposite symptom, no matches and nulls, which reads exactly like data not flowing through to the final table.
On the parallel refresh theory, I'd let that one go. Referencing doesn't work the way it looks like it does. There isn't a staging result that gets computed once and handed to the queries that reference it. From the guidance page: "it's often assumed that Power Query retrieves the Query1 result, and that it's reused by referenced queries. This thinking is incorrect." What actually happens is the staging steps get inlined into each query that references it and run again from scratch, and in the service it's stricter still, since each query refreshes using its own separate cache.
So there's no ordering to get wrong and no dependency setting to reach for, because the dependency you're picturing isn't there. Don't try to fix it with Table.Buffer either, the same page is explicit that a buffer only survives within a single query execution and that doing this can make it worse rather than better. If you genuinely want that staging table materialised once and read cheaply by everything downstream, that's a dataflow, which is what Microsoft recommends for exactly this shape.
I'd treat "field not found" as its own thing rather than a symptom of the same problem. That one usually means a column got renamed or dropped upstream and a later step is still asking for it by name.
How many rows does the right-hand query return, and is that key actually unique in it?
https://learn.microsoft.com/en-us/power-bi/guidance/power-query-referenced-queries
https://learn.microsoft.com/en-us/power-query/merge-queries-overview
