fix(inventory): network card mapping and port linking

[eduardomozart]

Checklist before requesting a review

Please delete options that are not relevant.

• 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

This PR addresses several interconnected issues regarding Device Network Cards (components) and Network Ports during native inventory imports, improving component identification, physical hardware grouping, and database relationships:
1. Accurate Hardware Model & Component Naming
Previously, network cards were being uniformly added as a generic "Network card item" without distinct names, causing them to group incorrectly in the Components tab and lack proper model identification. Because the networks schema doesn't have a name tag at all, this mapping fails to do anything. The parser now accurately sets the component's name (designation) to the interface's model, replacing the generic "Network card item" label on PCIVendor's product name fallback and resulting in much more accurate, user-friendly hardware identification.

2. Improved Controller Matching (Model Fallback)
The current logic strictly required the network interface's string description to perfectly match the controller's type or name. The controller matching loop has been expanded to also validate the controller's type against the network interface's model property.
3. Network Port Data Mapping (Speed and MTU)
Previously, key network interface data provided by the agent—such as speed and mtu—was being ignored on the base logical port due to GLPI's database schema split (glpi_networkports vs glpi_networkportethernets). InventoryNetworkPort and NetworkCard have been patched to correctly map these properties.

4. Fixing Controller Component Duplication
Previously, network cards were showing up on the Components page (once as "Controller" and twice as "Network card"). The root cause was that when a controller was mapped to a network interface, the parser attempted to add the interface's name ($val->name) to the ignored controllers list instead of the controller's name. Since network interfaces lack a name property in the inventory XML/JSON, the controller was never actually ignored. We fixed this by correctly using $found_controller->name.
Server-grade physical network cards very frequently have dual-ports or quad-ports (e.g., an Intel I350 Dual Port Gigabit adapter). On the hardware level, there is only one physical PCI controller chip processing the data. However, the operating system recognizes two separate logical network interfaces (eth0 and eth1). Therefore, the GLPI Agent accurately reports one CONTROLLER and two NETWORKS that both correctly point to that exact same controller.
5. Fixing Identical Interfaces Being Deleted
Fixing the bug above exposed another hidden bug: the controller matching logic previously skipped checking any controllers that had already been ignored (&& !isset($this->ignored['controllers'][$controller->name])). This meant that multi-port NICs (which have multiple network interfaces mapping to the exact same controller) would cause all subsequent network interfaces to fail to find a match and get entirely deleted from the NETWORKS inventory. We resolved this by removing the isset check, correctly allowing multiple interfaces to map to the same physical controller while keeping them neatly linked and successfully ignored as a standalone controller.
6. Network Ports failing to link to Network Card Components
During the inventory processing workflow in MainAsset.php, handlePorts() was being executed before handleAssets(). Because network ports rely on matching the MAC address of the network card components to establish their database link, this resulted in ports occasionally failing to associate with the hardware cards since the component rows hadn't been fully inserted into the database yet.

• Fix: Reordered the execution block in MainAsset::rulepassed() so that handlePorts() runs sequentially after handleAssets().

7. Testing & PHPStan Baseline Synchronization
Updated PHPUnit tests in NetworkCardTest.php to include a new test (testPhysicalAndVirtualNetworkCardsFallback) that proves virtual logical interfaces successfully separate from physical hardware controllers, and correctly handles multi-port interface assertions. The legacy test expectations in GenericNetworkAssetInventoryTest.php were also updated to accurately reflect the new port ordering logic. The .phpstan-baseline.php has been recalculated to align perfectly with the updated property definitions.

How to test

1. Ensure you are using a GLPI Agent build that includes glpi-agent#1176 so that network interfaces fallback with a MODEL and MANUFACTURER.
2. Import a native JSON/XML inventory containing network interfaces (including virtual/loopback interfaces and physical cards where the description does not match the controller->type string).
3. Go to Assets > Computers > [Your Computer] > Components. You should see virtual/unknown interfaces correctly omitted from the hardware list, while valid physical components successfully appear. The same component shouldn't appear twice as a Controller and a Network Card.
4. Verify that the components are named cleanly (using the PCIVendor's product name, falling back to the interface's model).
5. Go to the Network Ports tab and verify that the logical ports (e.g., eth0, lo, tun0) are correctly listed and successfully linked to their respective physical Network Card components where applicable.
6. Ensure the "MTU" and "Speed" columns are visible and accurately populated. Verify that the speed is correctly displayed in "Mbps" or "Gbps" and matches the expected hardware speed, and that the MTU reflects the agent's natively reported values.

Screenshots (if appropriate):

[trasher]

PR is incorrect. Changes are unrelated, no tests are added, etc.

[eduardomozart]

PR is incorrect. Changes are unrelated, no tests are added, etc.

Hello @trasher, thank you for your comment. In a later discussion, the GLPI team requested me to agglutinate my PRs for easier review, and I merged multiple fixes related to the network device in the same PR.
Beside the tests, can you provide me more details why do you think the PR is wrong? Thank you!

[cconard96]

In a later discussion, the GLPI team requested me to agglutinate my PRs for easier review, and I merged multiple fixes related to the network device in the same PR. Beside the tests, can you provide me more details why do you think the PR is wrong? Thank you!

Orthagh and I did ask for that, but specified that they need to be logically related. One of your PRs mixes KB, installer, and clipboard changes all in a single PR which are obviously not logically related.

In this PR the issue still exists but to a lesser degree. You have changes related to the inventorying of network cards mixed with component breadcrumb changes. I know it can be difficult from an external contributor perspective, but try to keep in mind that different areas of concern have different GLPI developers that are suitable for review. For example, I can easily review a PR that changes breadcrumbs but I am almost useless with any changes related to the inventory side so therefore I cannot truly approve this PR.

Try to think of logical groups of changes by their underlying feature area/module and if your PR titles need to have commas or descriptions need many sections, it is a good indicator that they need to be split. If you are addressing a bug in the inventory code, it shouldn't contain UI changes for somewhere else in the code. If a bug fix ends up causing issues, we don't want to have to sort through unrelated changes in the commit to troubleshoot or try to extract only the relevant changes for a revert commit.

[trasher]

Back to draft since Agent changes are not validated