fix item search entity restrict

[Megachip]

Checklist before requesting a review

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

Fixes an inconsistency where a recursive Ticket/Change/Problem cannot be
linked, via the item search dropdowns, to an asset located in one of its
sub-entities — even though the rights model already allows that exact
link.

Root cause

CommonDBRelation::can()'s entity coherency check
(src/CommonDBRelation.php) allows linking two items when either
extremity is recursive over an ancestor entity of the other:

if ($item1->isRecursive() && in_array($entity1, getAncestorsOf("glpi_entities", $entity2))) {
    return true;
}

So a recursive Ticket in entity Root can already be linked to a
NetworkEquipment in a child entity Root > Site A — can() returns
true.

However, CommonItilObject_Item::displayItemAddForm() passed the ITIL
object's own single entity ($obj->getEntityID()) as the
entity_restrict for the item search dropdowns
(dropdownAllDevices() / dropdownMyDevices()), with no downward
expansion for recursive objects. Down the call chain,
DbUtils::getEntitiesRestrictCriteria() only expands upward
(ancestors of the given entity) when the item being searched is
recursive — it never expands to the ITIL object's descendant
entities. For a Root-entity ticket, ancestors of Root are empty, so the
search criteria collapses to entities_id = 0: assets in any child
entity never appear as candidates, regardless of the ticket's own
recursivity.

Net effect: users had to split one logical ticket/change into N
per-entity tickets, purely because the search UI didn't surface
candidates the data layer already allowed linking to.

Fix

displayItemAddForm() now computes the search's entity scope as the
object's own entity plus all of its descendants (getSonsOf())
when the object isRecursive(), and leaves it unchanged (single
entity) otherwise. This only widens the candidate pool;
Session::getMatchingActiveEntities() — applied in
ajax/dropdownTrackingDeviceType.php and
Dropdown::getDropdownFindNum() — still narrows the actual result to
whichever entities are active in the current user's session, exactly
as for every other entity-restricted search in GLPI. A technician
still needs "Root + sub-entities" selected in the entity switcher to
see cross-entity results; this change doesn't grant new visibility, it
only stops hiding what the coherency check already permits.

Applies uniformly to Item_Ticket, Item_Change and Item_Problem,
since all three share CommonItilObject_Item.

Related prior art

#22851 removed a comparable, overly-strict entity restriction for
linked ITIL-to-ITIL objects (originally introduced by #10989), for the
same underlying reason: the restriction didn't match what the rights
model already allowed. That PR also flagged that session-based entity
filtering doesn't work in contexts without a "current user" (e.g.
notification rendering) — not applicable here, since this codepath is
only reached interactively from the item-search AJAX endpoint, which
always has a real session.

Tests added

• testItemAddFormEntityRestrictOnRecursiveItil (in
  AbstractCommonItilObject_ItemTest, so it runs for Ticket, Change and
  Problem): a recursive ITIL object's item search must include both its
  own entity and a child entity.
• testItemAddFormEntityRestrictOnNonRecursiveItil: a non-recursive
  ITIL object's item search must stay restricted to its own entity only.