feat(taskprocessing): add worker command for synchronous task processing

[Copilot]

Adds a taskprocessing:worker CLI command that runs a dedicated loop processing tasks via synchronous (ISynchronousProvider) providers, with starvation prevention via a single cross-type getNextScheduledTask query.

Summary

New command: occ taskprocessing:worker

• Polls for and processes tasks from all preferred synchronous providers
• --timeout <s>: exit after N seconds (default: run forever)
• --interval <s>: sleep between idle polling cycles (default: 1s)
• --once: process at most one task then exit
• --taskTypes <id>: restrict to specific task type IDs (repeatable)

Starvation prevention

Instead of shuffling providers and issuing one getNextScheduledTask call per provider, all eligible task type IDs are collected first and passed in a single query. This guarantees the globally oldest scheduled task is always picked next, regardless of per-provider queue depth:

// Build eligible taskTypeId → provider map for all preferred sync providers
$eligibleProviders = [];
foreach ($providers as $provider) { ... }

// One query across all types — picks oldest task, preventing starvation
$task = $this->taskProcessingManager->getNextScheduledTask(array_keys($eligibleProviders));
$provider = $eligibleProviders[$task->getTaskTypeId()];
$this->taskProcessingManager->processTask($task, $provider);

Test fixes

• createTask() helper now accepts an optional task type so task type IDs match provider expectations
• testProcessesFirstMatchingProvider → testProcessesCorrectProviderForReturnedTaskType: updated mock expectations to reflect that getPreferredProvider is called for every eligible provider and getNextScheduledTask receives all eligible type IDs
• Added testPicksOldestTaskAcrossMultipleEligibleProviders: verifies that with two eligible providers the task returned by getNextScheduledTask determines which provider runs

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[julien-nc]

Yay 👍 ❤️
Lgtm (didn't try it yet though). Will approve after trying it.

[julien-nc]

Works great

[szaimen]

Hey, is this the implementation for #52629 or is this something else?

[marcelklehr]

@szaimen This is something else. We discovered that the way TaskProcessing\SynchronousBackgroundJob works has some flaws that prevent seamless parallelism. So, for taskprocessing we've opted to leave the background job realm entirely and create a new command that runs the tasks in the background. (The alternative, in our view, would be to have one job per task which seems excessive.)

#52629 is separate from this effort and I realize that this PR distances us further from a unified solution. I'll pick up #52629 in our team discussion next week.

[kyteinsky]

🚀