When an LLD rule marks resources as "Lost" (e.g., by setting "Discover" to NO in the item prototype), the cleanup process executed by the "System" user after the "Keep lost resources period" expires behaves inconsistently if the discovered item is constrained by database integrity. The LLD trigger is deleted (causing mass event loss), but the parent discovered item is kept intact.

This was observed in an environment monitoring Meraki devices via API, where dependent triggers were created based on ping item prototypes.

Steps to reproduce:
1. Create an LLD rule that generates item prototypes and dependent trigger prototypes.
2. Allow the LLD to discover the items and triggers for a host.
3. Establish a dependency or link that might prevent the item from being deleted (e.g., link the discovered item to a manual static trigger, a custom graph, or use it in another calculated item).
4. Modify the LLD rule by setting "Discover" to NO for the item prototypes.
5. Wait for the "Keep lost resources period" to expire (e.g., 24h).

Result:
The "System" cleaner process deletes the discovered triggers, which cascades into deleting all associated historical events. However, the parent discovered item is not deleted (presumably blocked by DB integrity constraints). Re-enabling the item shows its history is fully preserved, confirming it was never removed from the `items` table, while its triggers and events are completely gone.

Expected:
The LLD cleanup process should be atomic and consistent. If a parent item cannot be deleted due to an integrity constraint, its dependent LLD triggers should not be deleted either. The system should ideally log a warning indicating that the resource could not be cleaned up due to constraints, rather than leaving the host in an orphaned state (items without their original triggers).

Analysis / Environment specifics:

• Database: MySQL 8.4 (Partitioned)
• Zabbix version: 7.0.19
• Housekeeper: Disabled
• The Zabbix Server deletes the trigger first, but when it attempts to delete the item, it is blocked. Because the trigger is deleted, all related events are purged to maintain DB referential integrity, causing unexpected mass event loss for the operations team.