general_multi_delete raises bare DoesNotExist, triggering deprecation warning it can never fix

[wussh]

Description

pulpcore.app.tasks.base.general_multi_delete looks up each instance by pk without handling the case where it no longer exists:

def general_multi_delete(instance_ids, **kwargs):
    instances = []
    for instance_id, app_label, serializer_name in instance_ids:
        serializer_class = get_plugin_config(app_label).named_serializers[serializer_name]
        instance = serializer_class.Meta.model.objects.get(pk=instance_id)
        ...

If the referenced object is deleted between task dispatch and execution (e.g. a racing delete, or overlapping cleanup in a test suite), Model.DoesNotExist propagates out of the task. Since DoesNotExist is not a PulpException/APIException/aiohttp.ClientError, _execute_task's deprecation check in pulpcore/tasking/tasks.py logs:

pulpcore.deprecation:WARNING: Exception (DoesNotExist: <Model> matching query does not exist.) will be sanitized in pulpcore 3.130

Where we hit this

Working on pulp_container, chasing CI's deprecations job failing intermittently across unrelated PRs (pulp/pulp_container#2438, #2439). We hardened all of pulp_container's own task-entry .objects.get() calls to raise a PulpException subclass instead (see #2439), but general_multi_delete (dispatched from ContainerDistributionViewSet.destroy and similar delete views across the plugin ecosystem) is pulpcore's own code, so plugins can't fix this from their side. Observed warnings:

pulpcore.deprecation:WARNING: Exception (DoesNotExist: ContainerDistribution matching query does not exist.) will be sanitized in pulpcore 3.130
pulpcore.deprecation:WARNING: Exception (DoesNotExist: ContainerRepository matching query does not exist.) will be sanitized in pulpcore 3.130

Impact

Since this exception is not a PulpException, per the changelog note in _execute_task, its message will be sanitized away entirely in pulpcore 3.130 — losing the actual missing-object detail for anyone debugging a failed delete task. It's also a source of nondeterministic CI noise for any plugin using general_multi_delete (or the async ageneral_delete/general_delete siblings, which have the same pattern) whenever a delete races with another delete of a related/reserved object.

Suggested fix

Wrap the .objects.get(pk=instance_id) lookup in general_multi_delete (and the general_delete/ageneral_delete siblings) to catch Model.DoesNotExist and re-raise as a PulpException subclass (e.g. something like ResourceGone/ObjectNotFound) so:

1. The real reason isn't sanitized away in 3.130.
2. Plugins relying on these generic delete tasks don't see spurious pulpcore.deprecation warnings for something outside their control.

[gerrod3]

We should catch the exception if the resource is already gone, but we should probably just skip it and move on to the next delete. Maybe log it in the task report or output.