Fix - Add explicit itemtype to search option for GLPI custom dropdown fields

[RomainLvr]

Checklist before requesting a review

Please delete options that are not relevant.

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

• It fixes !42293
• Here is a brief description of what this PR does

When a Fields block contains two GLPI custom dropdown fields (type dropdown-Glpi\CustomDropdown\...), selecting one of them in a bulk "Update" action displayed the values of the wrong dropdown.

In GLPI 11, all custom dropdowns share the same physical table (glpi_dropdowns_dropdowns). CommonDBTM::getValueToSelect() resolves the itemtype via $searchoptions['itemtype'] ?? getItemTypeForTable($searchoptions['table']). Since the table key was identical for all custom dropdown fields, getItemTypeForTable() returned the cached (wrong) itemtype, causing the values of one dropdown to appear in place of the other.

The fix explicitly sets $opt[$i]['itemtype'] in getAddSearchOptions() for non-multiple dropdown-XXXX fields, ensuring CommonDBTM::getValueToSelect() uses the correct itemtype directly without falling back to the ambiguous table-based lookup.

Screenshots (if appropriate):

CustomDropdowns structure :

CustomDropdown >

• CD1
• CD2
• CD3

Other Test >

• OT1
• OT2
• OT3

Before :

After :