Source: https://drupal.stackexchange.com/questions/315921/removing-phantom-plugin-from-database/320215#320215

It may happen that when you uninstall a module the procedure is not entirely carried out or there is no removal procedure present, for this reason the database remains "dirty".
Normally the error caused by forcibly removing a plugin is this:

[error]  Drupal\Component\Plugin\Exception\PluginNotFoundException:
         The "name-of-plugin" entity type does not exist.
         in Drupal\Core\Entity\EntityTypeManager->getDefinition()

Enabling the configuration that shows all error messages can help you understand where the error is present and where action needs to be taken.
You can activate full log enablement on the admin/config/development/logging page here. This configuration can help you figure out whether the problem is configurations or the plugin name is hard-coded into your code.

Now we will address how to resolve the problem if it is linked to configurations and to do so we have two possible ways:

• Exporting the entire configuration and re-importing it after removing the plugin references
• Acting directly on the configurations present in the db and removing the plugin

Exporting the entire configuration and re-importing it

This solution is most likely among the most used if you follow the standard release methodology recommended by the Drupal community.
Export the entire configuration through the graphical interface or with the drush config:export command. In the files recovered from the export, perform a full-text search with the plugin name. Remove the configuration section that is causing the error and import the configuration with drush config:import

By acting directly on the configurations present in the db and removing the plugin

This solution is useful for those who, like me, do not have the possibility of exporting the entire configuration and re-importing it but need to work "hot" on the site.
To find which configurations are causing the error you can run this query on the db:

SELECT name FROM config WHERE data LIKE "%name-of-plugin%";

The query searches the configuration table for the offending plugin and returns the names of the configurations that invoke the plugin.

When you have the names of the configurations you can proceed to remove the plugin.
Depending on the plugin and the configuration in error, the removal method may change slightly, now let's take into consideration an example which can also be a good starting point for other cases.

Ex.
I had a problem with the filter_image_lazy_load plugin due to a bad Drupal 10 update.
The previous query returned these configurations:

filter.format.basic_html
filter.format.full_html
filter.format.restricted_html

With the config.factory service I loaded the configurations and checked where the problem exists. Then you can proceed to remove the plugin like this:

$configName = 'filter.format.basic_html';
$config = \Drupal::service('config.factory')->getEditable($configName);
$filters = $config->get('filters');
unset($filters['filter_image_lazy_load']);
$config->set('filters', $filters)->save()

You can do the exact same thing with drush config:get filter.format.basic_html and drush config:set filter.format.basic_html or in one fell swoop with drush config:edit filter.format.basic_html

After cleaning the configurations run a drush cache:rebuild and the error should be resolved!