[2.x] fix: Unwrap RoutingQueue when identifying the queue driver

[imorland]

Why

#4853 wraps the queue connection in a RoutingQueue so push() can be routed by job class. ApplicationInfoProvider::identifyQueueDriver() derives the driver name from the connection's class name, so with the wrapper in place it now reports routing instead of the real backend (redis/database/sync).

This is visible on every 2.x site:

$ php flarum info
...
Queue driver: routing      # should be: redis / database / sync

It also surfaces on the admin dashboard, and it breaks downstream code that keys off the reported driver — e.g. fof/horizon relabels redis → Redis + Horizon and gates its admin controls on that, so those controls silently disappear.

What

Unwrap a RoutingQueue via its public getDriver() before reading the class name, so the reported driver reflects the actual backend again:

$queue = $this->queue instanceof RoutingQueue
    ? $this->queue->getDriver()
    : $this->queue;
$queue = $queue::class;
// ...strip namespace, lowercase, drop 'queue'

Tests

ApplicationInfoProviderTest gains:

• queue_driver_is_derived_from_the_connection_class — a bare SyncQueue reports sync.
• queue_driver_reports_the_real_driver_when_wrapped_in_a_routing_queue — a SyncQueue wrapped in a RoutingQueue still reports sync, not routing.

The provider() helper takes an optional queue instance so a specific connection can be injected.

Full ApplicationInfoProviderTest green (8 tests). Verified live: php flarum info reports redis again on a redis-backed stack.

Regression from

#4853 (the RoutingQueue connection wrapper).