[13.x] Add Worker Pausing/Resuming Events

@jackbayliss merged PR #59895 into laravel/framework for the 13.x branch, adding two new events fired when a queue worker pauses or resumes in response to OS signals.

The Gap

When infrastructure sends a SIGUSR2 to pause a worker, or a SIGCONT to resume it, the worker handled both signals internally with no way for userland code to know either had occurred. If you were tracking worker health, logging state transitions, or coordinating with an external process manager, you were flying blind.

This PR closes that gap with two dedicated events: WorkerPausing and WorkerResuming.

The New Events

The worker now dispatches WorkerPausing when it receives SIGUSR2 and WorkerResuming when it receives SIGCONT. Listening to them works exactly like any other Laravel event.

 1use Illuminate\Queue\Events\WorkerPausing;
 2use Illuminate\Queue\Events\WorkerResuming;
 3 
 4Event::listen(WorkerPausing::class, function (WorkerPausing $event) {
 5    Log::info('Queue worker pausing', ['worker' => getmypid()]);
 6});
 7 
 8Event::listen(WorkerResuming::class, function (WorkerResuming $event) {
 9    Log::info('Queue worker resuming', ['worker' => getmypid()]);
10});

Register those listeners in AppServiceProvider::boot() or wire them through EventServiceProvider as normal.

Who Should Care

Any team running queue workers under a process supervisor that uses SIGUSR2 and SIGCONT for graceful pause and resume (Supervisor's signal command, Kubernetes lifecycle hooks, custom infra tooling) now has a first-class hook into those transitions. This is particularly useful for draining metrics, flushing buffers, or updating an external health-check endpoint the moment a worker changes state.

Three files changed and 49 net lines added. No tests ship with the PR, as @jackbayliss noted, because signal-based behavior does not lend itself to automated testing in the framework's test suite.