Update delete task to skip over already deleted objects

[gerrod3]

Also added delete results output to the tasks.

fixes: #7910
Generated by: cursor-grok-4.5

📜 Checklist

• Commits are cleanly separated with meaningful messages (simple features and bug fixes should be squashed to one commit)
• A changelog entry or entries has been added for any significant changes
• Follows the Pulp policy on AI Usage
• (For new features) - User documentation and test coverage has been added

See: Pull Request Walkthrough

[gerrod3]

This only covers the case where the user dispatches multiple delete tasks on the same object. Every N+1 task will no result in a no-op instead of error. However, there are still many scenarios where the delete can fail that isn't caught with this change. Here are some AI thought of:

Business-rule / hook failures

RepositoryVersion: last complete version → APIException
RepositoryVersion: protected version → BEFORE_DELETE raises
RepositoryVersion: squash didn’t clear memberships → RuntimeError
Other BEFORE_DELETE hooks (domains, remotes, etc.)

Integrity / relation failures

ProtectedError / RestrictedError when related rows block the delete (PROTECT/RESTRICT), e.g. ContentArtifact → Artifact, AlternateContentSource → Remote, RepositoryContent.version_added/removed → RepositoryVersion
Other DB integrity errors from cascade cleanup

Concurrency / ordering

Object (or a later multi-delete target) removed between get/cast and delete
In general_multi_delete, deleting A cascades away B still in the list → later B.delete() can fail or delete nothing
Deadlocks / lock waits (notably RepositoryVersion’s select_for_update)

Operational

DB timeouts, disconnects, OOM on large cascade trees
Nested work inside overrides (cache, bulk _raw_delete, etc.) raising unexpectedly
general_multi_delete specifically

One failing delete() aborts the outer transaction.atomic(), so earlier deletes in that batch roll back.

Usually not task failures

Artifact file removal runs on transaction.on_commit, so storage errors there don’t fail the delete call itself.

[gerrod3]

Some questions about logging:

1. What is our current policy of using gettext? Should we still be wrapping log statements inside it?
2. Does something like this deserved to be logged if we put it in the task output? I didn't tell the AI to remove the logs after adding the output, but my general question is what things are important enough that they need to be logged?

[gerrod3]

Task outputs can be anything as long as they are serializable, correct?