fix(AppDisableListener): pass full provider key to deleteProvider

[weltmaister]

Summary

AppDisableListener schedules a delete_provider_id action using the bare provider id (e.g. mail) instead of the full provider key appId__providerId (e.g. mail__mail). The backend rejects the bare id (is_valid_provider_id, ^[a-zA-Z0-9_-]+__[a-zA-Z0-9_-]+$).

Because context_chat_backend's updates_processing_thread validates the whole ActionsQueueItems batch in a single model_validate() call, this one invalid item makes it throw on every poll and freezes the entire oc_context_chat_action_queue indefinitely — access-declaration updates, deletions, etc. stop propagating and it never recovers on its own.

Details in #258.

Fix

$key already holds the correct full key (appId__providerId), so pass it directly to ActionScheduler::deleteProvider() instead of the split-off $providerId.

Also documented on ActionScheduler::deleteProvider() that it expects the full appId__providerId key (as returned by ProviderConfigService::getConfigKey()), matching every other caller.

Trigger / impact

AppDisableEvent fires whenever an app that registered a content provider is disabled — including during app updates / occ upgrade. The Mail app registers provider id mail, so each disable produced one poisoned delete_provider_id: mail row. Observed effect: 500+ update_access_decl_source_id actions stuck for ~1 day; ACL/share changes not reflected in semantic search until the poison rows were removed manually.

Note

Secondary hardening — updates_processing_thread validating/skipping per item (like the files path already does via ItemValidationError) instead of aborting the whole batch — belongs in context_chat_backend and is out of scope here.

[kyteinsky]

thanks!