[1.x] perf: add MemoryCacheSettingsRepository layer to eliminate per-call Redis fetches

[imorland]

Problem

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).

Flarum core's SettingsServiceProvider uses MemoryCacheSettingsRepository to provide a per-request in-process cache — one load, then array lookups. fof/redis's Settings provider replaces the entire binding without restoring this layer.

Fix

Wrap 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.

Impact

Expected Redis egress reduction: ~95%+ of settings-related bandwidth eliminated. On production (Nothing Community), this should bring Redis outbound bandwidth from ~300 Mbps down to ~5–15 Mbps.

No behaviour change — invalidation on ClearingCache, Enabled, Disabled events is unchanged. The memory cache is request-scoped (PHP-FPM worker lifetime), so settings changes propagate on the next request after Redis invalidation.