v8.5.32

⚠️ Fix: two installs sharing an FPM pool shared one security-event budget

The rolling cap on type=security reports counted into
ovos:console:security:<minute> whatever the install. APCu belongs to the whole pool
and a pool can serve several — prod and test on one box, a handful of tenant vhosts —
so they all spent the same SECURITY_MAX_PER_MINUTE allowance.

The failure mode is quiet on both sides: a credential-stuffing wave against one install
reports its own 60 events a minute as designed, and the install next to it, doing
nothing unusual, has its auth failures silently dropped for as long as the wave lasts —
precisely when they are worth having.

Sender::securityKey() now puts the install's configured cache prefix
(cache.prefix, typically !ENV CACHE[PREFIX]) in front of SECURITY_PREFIX, joined
by the same Cache\Prefixer the cache stores use, with cachePrefix() — added in
v8.5.30 for the rollup counters — reading it off the app config. It is public static,
so the key can be asserted without touching APCu.

This was the last hardcoded APCu key in the sender; a scan of src/ found no other
(everything else keys off an injected prefix or a cache id). It is the same defect the
rollup counters had in v8.5.30, one key further along.

Inert where it does not apply: an install that configures no cache prefix keeps the
key it had. Where it does apply, the counter restarts once, inside its own 120 s window.

Tests: theSecurityCapCountsPerInstall — two installs key apart, one install still
shares a counter across its workers, the minute still rolls, and no prefix leaves the
key unchanged.