Tree: Fix incorrect error notification when deleting last child (closes #20977)

[iOvergaard]

Summary

Fixes #20977 - Addresses issues with tree loading after deleting document types, including inappropriate error notifications and potential JavaScript errors.

Changes

Primary Fix: Contextual Error Notifications

The main user-facing issue was an inappropriate "Menu loading failed" error notification appearing when deleting the last child of a tree node, where an empty tree is the expected outcome.

• Added ResetReason type to differentiate between actual errors and expected empty states ('error' | 'empty' | 'fallback')
• Updated #resetChildren() in tree-item-children.manager.ts to accept a reason parameter and only show error notifications when the reason is 'error'
• Updated all call sites to provide appropriate context:
  • When retries are exhausted → 'error' (shows notification)
  • When no target is found after deleting items → 'empty' or 'fallback' (no notification)

This ensures users only see error messages for actual failures, not for legitimate empty states.

Additional Safeguard: Undefined Items Protection

While investigating, we identified a potential issue in the tree-data.request-manager.ts where #getTargetResultHasValidParents() could receive undefined data and call .every() on it, which would cause:

TypeError: can't access property "every", e is undefined

Added a guard to check if data is undefined before calling .every(), returning false to trigger proper error handling. This is a defensive safeguard that prevents potential crashes if the backend API returns unexpected data structures.

Additional Safeguard: Recursion Prevention

While investigating this issue, we discovered a potential infinite recursion vulnerability in the tree loading logic. The #resetChildren() method could call loadChildren(), which under certain failure conditions would recursively call #resetChildren() again, creating an infinite loop.

To prevent this scenario:

• Extracted #loadChildrenWithOffsetPagination() as a terminal fallback method that uses only offset pagination and structurally cannot recurse
• Updated #resetChildren() to call this fallback instead of loadChildren(), making infinite recursion impossible by design
• Added explicit reset of all retry counters (#loadChildrenRetries, #loadPrevItemsRetries, #loadNextItemsRetries) to ensure clean state

The fix creates a one-way flow: target-based loading can fall back to #resetChildren(), which calls offset-only loading that never recurses back.

Testing

• Verified that deleting the last child of a tree node no longer shows an error notification
• Confirmed that legitimate error scenarios (retry exhaustion) still show appropriate notifications
• Validated that the recursion safeguards prevent potential infinite loops under failure conditions
• Added defensive checks to prevent crashes from unexpected API responses

[Copilot]

Pull request overview

This PR fixes an issue where users were incorrectly shown a "Menu loading failed" error notification when deleting the last child of a tree node, despite this being an expected empty state. The fix differentiates between actual errors and legitimate empty states by introducing contextual error notifications, and adds safeguards to prevent potential infinite recursion in the tree loading logic.

• Added ResetReason type to distinguish between errors, empty states, and fallback scenarios
• Extracted #loadChildrenWithOffsetPagination() as a terminal fallback that prevents infinite recursion
• Updated all call sites to provide appropriate context when calling #resetChildren()

[leekelleher]

I've tested it out, it functionally works as described.
I do think @madsrasmussen should review the code changes before we approve/merge this.

[madsrasmussen]

Great! changes look good to me