Bulk-content-removal safeguard counts archived contentlets, blocking legitimate container operations

Problem Statement

The safeguard recently introduced to prevent unwanted removal of multiple contentlets at once counts contentlets in every state — including archived (deleted = true) ones — when evaluating whether an operation would remove "too many" contentlets from a container.

Because a contentlet's archived version can still have a stale row in multi_tree (e.g. left over from before archiving a contentlet was changed to automatically remove it from its container), the safeguard's count is inflated by content that is no longer actually "in use." This causes it to incorrectly block legitimate container/page operations that should be allowed, since the operation looks like it would remove more live content than it actually would.

Impact: low-frequency (requires a container to already hold a stale archived-contentlet reference), but when it hits, it fully blocks the affected operation with no workaround other than manually cleaning up the stale multi_tree row.

Steps to Reproduce

1. Have a container with a multi_tree row referencing a contentlet identifier whose contentlet_version_info.deleted = true (archived) for the relevant language/variant — for example, a row that predates the fix that makes archiving a contentlet automatically remove it from its container.
2. Perform an operation that triggers the bulk-removal safeguard (e.g. saving/reordering content in that container via the page editor / UVE, or the equivalent API call).
3. Expected: the safeguard only counts non-archived (working/live) content toward its removal threshold, and the operation proceeds normally.
4. Actual: the safeguard also counts the archived contentlet, inflating the removal count and incorrectly blocking the operation.

Acceptance Criteria

• The bulk-removal safeguard's contentlet count only considers non-archived content (contentlet_version_info.deleted = false) for the relevant identifier/language/variant.
• A container holding a stale archived-contentlet reference in multi_tree no longer trips the safeguard on an otherwise-valid operation.
• The safeguard continues to correctly block bulk removal of non-archived content (no regression to its original intent).
• Covered by a unit/integration test that seeds an archived contentlet reference in multi_tree and asserts the safeguard does not count it.

dotCMS Version

Reproducible on any version that includes the "auto-remove from container on archive" change plus the bulk-removal safeguard (both recently introduced). See linked Freshdesk ticket for the specific environment where this was reported.

Severity

Medium - Some functionality impacted

Links

• Freshdesk ticket #39004