/item command selects fewer slots than expected with nested `limit_slots` in a `group` slot source

When an /item command uses a limit_slots slot source that wraps a group whose entries each contain their own limit_slots, the selection counter is incorrectly shared across the entries. As a result, selecting a slot in one entry can prevent subsequent entries from selecting slots, even when those entries' individual limits have not been reached.

Steps to Reproduce

1. Put an item in hotbar.0 and another item in hotbar.1.

2. Run the following command:

   /item modify entity @s {type:limit_slots,limit:2,slot_source:[{type:limit_slots,limit:1,slot_source:{type:slot_range,slots:"hotbar.0"}},{type:limit_slots,limit:1,slot_source:{type:slot_range,slots:"hotbar.1"}}]} {type:set_count,count:1,add:true}

Expected Result

Both hotbar.0 and hotbar.1 are modified, as each entry in the group selects one slot and the outer limit_slots allows up to two slots to be selected.

Actual Result

Only hotbar.0 is modified, and the command outputs "Modified 1 slot(s) on <username>"

Additional test case

To compare the behavior, run the following /execute if slots command:

/execute if slots entity @s {type:limit_slots,limit:2,slot_source:[{type:limit_slots,limit:1,slot_source:{type:slot_range,slots:"hotbar.0"}},{type:limit_slots,limit:1,slot_source:{type:slot_range,slots:"hotbar.1"}}]}

It outputs "Test passed. Count: 2", indicating that two slots were selected. This differs from the number of slots modified by /item modify, even though both commands use the same slot source. At least one of the two commands is wrong, and I suspect that /item is the one behaving incorrectly.