Fix workers() not respecting user-specified order

[kayw-geek]

Summary

Fixes #111

MBConfig::workers() does not respect the user-specified worker order. When users call disableDefaultWorkers() and then register workers in a specific order via workers(), the default workers (TagVersion, PushTag) always run first.

Root cause

config/config.php registers default workers (TagVersionReleaseWorker, PushTagReleaseWorker) first. When MBConfig::workers() later calls $services->set(SameClass), it replaces the definition but PHP arrays preserve the original key position — so the workers stay at the front of the container's definitions array regardless of the user's intended order.

Additionally, replacing the definition causes the monorepo.default_worker tag to be lost, making RemoveDefaultWorkersCompilerPass unable to find and remove them.

Fix

• MBConfig::workers() now registers services with unique IDs (user_release_worker.{index}) instead of using the FQCN, so they are appended to the end of the definitions array in the user's specified order.
• RemoveDefaultWorkersCompilerPass now also removes default workers whose class overlaps with user-registered workers (even without disableDefaultWorkers()), preventing duplicates.

Test coverage

Scenario	Expected
Default behavior, no workers() call	TagVersion + PushTag registered
disableDefaultWorkers() only	No workers
disableDefaultWorkers() + workers([TagVersion])	Only TagVersion
workers([Custom, TagVersion, PushTag]) without disableDefaultWorkers()	User order, no duplicates
disableDefaultWorkers() + workers([Custom, TagVersion, PushTag])	Exact user-specified order