[2.x] feat: phpredis auto-detect, cache:subscribe fix, settings memory cache

[imorland]

Changes

1. Auto-detect phpredis, fall back to Predis

Detects the available Redis client at runtime rather than assuming Predis. If the phpredis extension is loaded, it is used directly; otherwise falls back to Predis. No configuration change required.

2. Fix cache:subscribe with phpredis

The cache:subscribe command was hardcoded to check instanceof \Predis\Client, causing it to abort immediately when phpredis is active. Replaced with driver-agnostic routing:

• phpredis: uses callback-based subscribe() with OPT_READ_TIMEOUT = -1 and $redis->close() to exit on --once
• Predis: existing pub/sub loop preserved, creates a new client with read_write_timeout: 0

3. Add MemoryCacheSettingsRepository layer to eliminate per-call Redis fetches

RedisCacheSettingsRepository::get() calls all() on every invocation, which calls cache->remember() every time — a Redis GET of the full flarum:settings blob on each call.

On a typical forum page, settings are read 60–100 times (core serializers, frontend JS variable injection, middleware, extensions). Each call fetches the entire settings blob from Redis — on production this is ~154 KB. That's up to ~15 MB of Redis egress per page load from settings reads alone, which at scale accounts for the majority of observed Redis outbound bandwidth (~300 Mbps on Nothing Community).

Flarum core's SettingsServiceProvider uses MemoryCacheSettingsRepository to provide a per-request in-process cache. fof/redis's Settings provider replaced the entire binding without restoring this layer.

The fix wraps RedisCacheSettingsRepository with MemoryCacheSettingsRepository, restoring the three-layer chain:

MemoryCacheSettingsRepository   ← per-request in-process cache (zero network cost after first read)
  └── RedisCacheSettingsRepository  ← cross-request Redis cache (one Redis GET per request, 1h TTL)
        └── DatabaseSettingsRepository  ← source of truth (MySQL, hit only on Redis miss)

After this change, Redis is hit at most once per request for settings instead of once per settings->get() call. Expected Redis egress reduction: ~95%+ of settings-related bandwidth eliminated.