## Summary

When an onchange fires on a wizard with a large x2many field, the server returns a batch of LINK commands that `_applyCommands` iterates over. The `Array.includes()` guard against duplicates was $O(N)$ per command, making the full loop $O(M×N)$, where $N$ is the size of the `_currentIds` list and $M$ is the number of commands. 

This change builds a local `Set` from `_currentIds` once before the loop so each membership check is $O(1)$ on average.

## Affected examples

This is a generic issue that surfaces on any wizard whose onchange returns a large number of LINK commands. 
Two known cases:

- **Add to Documents** (chatter button): opens the `documents_operation` wizard, whose `destination_children_ids` field can receive a large batch of LINK commands when the destination folder has many children.
- **Refund** on a Helpdesk ticket: opens the `account_move_reversal` wizard, where `suitable_sale_order_ids` and `suitable_move_ids` are populated via onchange and can contain tens of thousands of records depending on the customer's history.

In both cases the slowdown scales with the product of the number of incoming commands and the current size of the x2many, which becomes noticeable once either dimension reaches the thousands.

## Benchmarks

Measured on customer databases where the onchange returns a large number of LINK commands.

| Scenario | Before | After |
|---|---|---|
| Add to Documents (64k docs under default folder) | ~7 min  | ~8s |
| Helpdesk Refund (60k linked lines) | ~5m 40s | ~5s |

OPW-6069884
OPW-6099516