Add shared operations to make pending sync retries due on the next cron run

Problem/Motivation

Provider-backed video asset rows can enter retry states such as pending_sync after a recoverable failure. A common example is a provider configuration or runtime issue that is later fixed, while existing asset rows are still scheduled to wait for their normal retry window.

In those cases, maintainers need a safe operational way to make scheduled retries due immediately so the next cron run can retry them with the current runtime configuration.

Today there is no shared recovery tool in video_style for that. Operators have to wait for the normal retry window or manipulate data manually.

Steps to reproduce

1. Install video_style with a provider module that performs asynchronous derivative synchronization and stores retry metadata.
2. Cause one or more tracked asset rows to enter pending_sync with a future retry timestamp.
3. Fix the root cause, for example by correcting provider runtime settings.
4. Open /admin/config/media/video-styles/assets.
5. Observe that there is no shared operational action or command to make those pending retries due on the next cron run.

Proposed resolution

Add shared operational recovery support to video_style.

The base module should provide:

• a shared operations section on /admin/config/media/video-styles/assets,
• a generic Drush command such as drush video-style:retry-due-now, and
• a provider opt-in contract so provider modules can expose retry-reset behavior without hardcoded provider conditionals in video_style.

The shared action should:

• only make existing scheduled pending sync retries due immediately,
• not process derivatives inline,
• leave the actual retry execution to the existing cron and queue pipeline,
• preserve attempt counters and last error details, and
• allow providers with retryable asset work to implement the behavior through a shared handler contract.

The operations UI should always be visible on the asset page, but the action should be disabled when there are no scheduled retries that can be reset.

Remaining tasks

• Add a shared retry-reset handler contract and registry in video_style.
• Add a shared retry-reset manager to coordinate provider implementations.
• Add shared repository helpers for counting and resetting scheduled pending sync retries.
• Add an operations form to the shared asset page.
• Add a generic Drush command for the same operation.
• Document the new operational workflow in README and help text.

User interface changes

Yes.

The shared asset administration page gains an Operations section with an action to make pending sync retries due on the next cron run. The section should follow normal Drupal admin UI patterns and remain visible even when the action is currently disabled.

API changes

Yes.

The base module gains a new shared provider opt-in contract for retry-reset operations so provider modules can participate without new provider-specific conditionals in video_style.

Data model changes

No.

This feature operates on existing retry metadata such as pending sync status and retry timestamps. It does not require a schema or config model change.