[app] Resources review: memory ratios, infra CPU requests, document the no-CPU-limits decision

[henzigo]

Context

• php-fpm memory request:limit is 1:4 (500Mi vs 2Gi) — Burstable QoS with a big
  overcommit window, first eviction candidate under node pressure; pm.max_children: 20
  alone can consume ~1.6 Gi
• redis CPU request 100m and rabbitmq 20m are far below realistic usage
• redis-exporter 10m/128Mi with equal limit — throttling/OOM risk on INFO spikes
• nginx 300Mi limit is tight for connection buffering under load
• CPU limits are intentionally omitted (legacy PR Add default readiness/liveness probes to the RabbitMQ StatefulSet #53, throttling avoidance) — the decision
  is right but undocumented in the chart

Proposal

• align php-fpm memory request to ~1:2 ratio (e.g. request 1Gi, limit 2Gi), correlate with
  the php-fpm pool sizing issue ([app] Runtime config tuning: php-fpm pool, FPM access log, opcache, redis eviction policy #37, if accepted)
• raise redis (300m), rabbitmq (250m), redis-exporter (20m, limit 100m/256Mi) and
  nginx (100m/150Mi, limit 512Mi) requests to realistic baselines — validate against
  Prometheus data from a reference project before merging
• document the no-CPU-limits decision as a comment in values.yaml next to each resources block
• dev overlays keep their downscales

Tasks

• Metrics-validated new defaults
• values.yaml comments for the CPU-limits decision
• Golden snapshots, deviations entry
• docs/values.md note

Related: #4, #27