Perf: orderAfterMerge recomputed inside the parent-plugin loop (O(P^3))

## Summary
`ModelUtils.mergePluginLists()` recomputes `orderAfterMerge(...)` — and calls `setPlugins`/`flushPluginMap` — on **every** iteration of the parent-plugin loop, even though the loop body already accumulates into `assembledPlugins`.

`src/main/java/org/apache/maven/plugin/resources/remote/ModelUtils.java:81-117`

```java
for (Plugin parentPlugin : parentPlugins) {
...
// very important to use the parentPlugins List ...
List results =
ModelUtils.orderAfterMerge(assembledPlugins, parentPlugins, childContainer.getPlugins());
childContainer.setPlugins(results);
childContainer.flushPluginMap();
}
```

`orderAfterMerge` walks both full plugin lists (`:121-163`) with `results.contains`/`indexOf` linear scans.

## Impact
For P parent plugins this is O(P³) work in the worst case plus repeated map flushes — mostly negligible for typical plugin counts but quadratic-to-cubic during supplemental-model merges with many plugins. The ordering result is identical whether computed once at the end or per-iteration, so the per-iteration call is pure waste.

## Suggested fix
Hoist `orderAfterMerge(...)` + `setPlugins`/`flushPluginMap` out of the loop and compute them once after the loop finishes.

Start in src/main/java/org/apache/maven/plugin/resources/remote/ModelUtils.java, especially mergePluginLists() at lines 81-117 and orderAfterMerge() at lines 121-163. Move the ordering and plugin-map updates to after the parent-plugin loop, then verify that the ordering result remains unchanged and repeated map flushes are eliminated.

Written by the indexing model from the issue text.