feat(litespeed): wire up dynamic LSAPI tuning + idle reduction

Two correctness fixes and a tuning improvement.

CORRECTNESS:
1. Strip the stock 'extProcessor lsphp' from httpd_config.conf before
   appending ours. Previously the stock block (hard-coded
   PHP_LSAPI_CHILDREN=10 regardless of container memory) always won
   because our APPEND fragment didn't include an extProcessor block.
   detect-memory-litespeed.sh was computing LSAPI_CHILDREN but never
   plumbing it anywhere — silent dead code.

2. Bump LSPHP_WORKER_ESTIMATE_MB from 96 → 115 per the 2026-06-02
   memory-sizing finding (vantagehealth OOM-spawn loop). Each lsphp
   carries ~115 MB shmem-rss accounted per worker. 115 MB matches the
   real per-worker baseline.

TUNING (idle reduction, the original ask):
- LSAPI_MAX_IDLE_CHILDREN=2  (was CHILDREN/2 = 5 default)
- LSAPI_MAX_IDLE=60s         (was 300s default)
- PHP_LSAPI_MAX_REQUESTS=500 (recycle workers, prevents bloat)
- memSoftLimit=1024M / memHardLimit=1500M per worker (RLIMIT_AS;
  catches runaway scripts at the worker level, cgroup still backstops
  the container)

Effective LSAPI_CHILDREN per container:
  2 GiB → ~17 (was 10 — brain-jar was saturating)
  1 GiB → ~8
  512 MiB → ~3 (cap-marginal per the memory note; bump container if
                site grows)

Dropped LSAPI_MEM_SOFT/HARD computation in detect-memory: AVAILABLE/CHILDREN
was conflating VSZ with RSS-budget arithmetic and would have killed
legitimate workers. The 1024/1500 hard-coded values in the template
comfortably fit typical Divi/WooCommerce VSZ (280-365 MB).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

scripts/detect-memory-litespeed.sh

@@ -47,9 +47,16 @@ if [ "$AVAILABLE_MB" -lt 60 ]; then
 fi
 
 ## ---- LSAPI children (analogous to PHP_FPM_MAX_CHILDREN) ----
-## LSAPI is more memory-efficient than FPM; estimate 96 MB / worker
-## (vs 128 MB for FPM after the 2026-06-01 bump). Floor 2, cap 50.
-LSPHP_WORKER_ESTIMATE_MB=${LSPHP_WORKER_ESTIMATE_MB:-96}
+## Per the 2026-06-02 cac-litespeed memory-sizing finding (vantagehealth
+## OOM-spawn loop at 512 MB cap): each lsphp worker carries ~115 MB
+## shmem-rss which is RSS-accounted per worker (vs cac-fpm's COW-shared
+## fork model). Real-world worker budget ≈ 115 MB shmem + ~50-100 MB anon
+## that scales with workload. 115 MB is the safe per-worker estimate for
+## the divisor; floor at 2, cap at 50.
+##
+## Sub-512 MB containers are unsafe for dynamic WP on OLS per the memory
+## note — the floor of 2 workers still applies but it'll be cap-marginal.
+LSPHP_WORKER_ESTIMATE_MB=${LSPHP_WORKER_ESTIMATE_MB:-115}
 
 calc_lsapi_children=$((AVAILABLE_MB / LSPHP_WORKER_ESTIMATE_MB))
 if [ "$calc_lsapi_children" -lt 2 ]; then
@@ -64,13 +71,11 @@ fi
 ## else the calculated value.
 LSAPI_CHILDREN=${LSAPI_CHILDREN:-${FPM_MAX_CHILDREN:-$calc_lsapi_children}}
 
-## extprocessor mem limits — total LSAPI heap should fit AVAILABLE_MB with
-## some breathing room. Soft = budget/children, hard = soft * 1.5, both capped
-## at 2047 (OLS interprets > 2047 oddly in some 1.x builds).
-LSAPI_MEM_SOFT=$((AVAILABLE_MB / LSAPI_CHILDREN))
-if [ "$LSAPI_MEM_SOFT" -lt 64 ]; then LSAPI_MEM_SOFT=64; fi
-if [ "$LSAPI_MEM_SOFT" -gt 2047 ]; then LSAPI_MEM_SOFT=2047; fi
-LSAPI_MEM_HARD=$((LSAPI_MEM_SOFT * 3 / 2))
-if [ "$LSAPI_MEM_HARD" -gt 2047 ]; then LSAPI_MEM_HARD=2047; fi
+## Per-worker mem limits (RLIMIT_AS) live in httpd_config.tpl now as
+## hard-coded 1024M soft / 1500M hard — those values comfortably fit
+## typical Divi/WooCommerce VSZ (~280-365 MB) while still catching a
+## true runaway script. Cgroup remains the real backstop. The earlier
+## AVAILABLE/CHILDREN formula was killing legitimate workers because
+## it conflated VSZ (RLIMIT_AS) with RSS-budget arithmetic.
 
-export CONTAINER_MEMORY_MB LSAPI_CHILDREN LSAPI_MEM_SOFT LSAPI_MEM_HARD
+export CONTAINER_MEMORY_MB LSAPI_CHILDREN