[13.x] Boot managed queues before service providers boot (#60198)

* Boot managed queues before service providers boot

The `cloud` queue connector was registered on the `bootstrapperBootstrapped: BootProviders` event, meaning it fired after every service provider's `boot()` had already run. Application providers whose boot logic touches the queue (e.g. `Queue::createPayloadUsing(...)`, which proxies through `QueueManager::__call` and resolves the default connection) blow up under `QUEUE_CONNECTION=cloud` with "The [cloud] queue connection has not been configured", because the connector isn't registered yet.

Move `bootManagedQueues()` to `bootstrapperBootstrapping: BootProviders` so it runs after `RegisterProviders` (queue/queue.failer are bound) but before any user provider's `boot()`.

Also refactor the early-return guard. The previous check on `$_SERVER['LARAVEL_CLOUD_MANAGED_QUEUES']` overlapped with the env-driven config that `configureManagedQueues()` already populates. Derive intent from observable state instead: only register the cloud connector if `queue.connections.cloud.driver === 'cloud'`. The outer `laravel_cloud()` gate in `Application::registerLaravelCloudServices()` already prevents these hooks from firing off-Cloud.

* Drop unused LARAVEL_CLOUD_MANAGED_QUEUES env from test setup

No production code reads this env var anymore — the previous commit replaced its only consumer (the guard in `bootManagedQueues`) with a check on `queue.connections.cloud.driver`. The setUp/tearDown lines in `tests/Foundation/Cloud/QueueTest.php` are the only remaining references; remove them.

`LARAVEL_CLOUD_MANAGED_QUEUES_CONFIG` is a different env var and is still consumed by `configureManagedQueues()` — left in place.