Add a state-based persistence-child detector that flags a fork child
whose key progress freezes, whose elapsed time exceeds a ceiling, or
whose last bgsave/bgrewrite status flips to error. Emits a new
PERSISTENCE_CHILD metric and PERSISTENCE_STALL correlation pattern
with remediation guidance. Thresholds are env-configurable.

Add PERSISTENCE_STALL pattern, persistence_child metric, and the
MONITOR_PERSISTENCE_* threshold env vars to the anomaly detection guide.

Per-episode persistence tracking was reset only when a poll observed
in_progress=0. A BGSAVE/AOF rewrite that finished and restarted between
polls (tight save cadence, slow interval, or a failed poll) reused the
prior PersistenceChildTrack, causing a false CRITICAL stall from a stale
lastAdvanceTs or suppressing alerts for a genuinely stuck new child via a
carried-over reportedStall/warnedLong.

A running child's elapsed time and processed-key count are monotonic
within an episode and reset when a new fork starts. Detect a regression in
either signal and re-baseline the track (clearing the reported flags),
mirroring the first-observation branch. Covers RDB (elapsed or processed)
and AOF (elapsed only, no per-key progress).

Address PR review feedback on the BGSAVE/AOF rewrite stall detector:

- Move the three MONITOR_PERSISTENCE_*_SEC thresholds into the Zod env
  schema (env.schema.ts) and read them plainly, so a typo fails startup
  validation instead of silently falling back, matching every other
  MONITOR_* threshold.
- Report a pre-existing err status. Persistence-child error detection is
  now level-triggered with a latch: an err already present at monitor or
  connection start fires on the first poll, a persisting err fires once,
  and a later ok re-arms it for the next failure.
- Distinguish the elapsed-time ceiling from a frozen-progress stall. When
  a child crosses persistenceCritSec its event now carries threshold=crit
  and a "time ceiling" message instead of the stall shape (threshold=60,
  "no progress"), which was misleading when keys were still advancing.

Adds tests for the pre-existing err, the latch dedup/re-arm, and the
time-ceiling reason; updates the ConfigService mock to return the
schema-validated numeric thresholds.

…tall

Addresses review feedback on #294. The frozen-progress stall check fired
whenever current_save_keys_processed stayed flat for persistenceStallSec while
rdb_bgsave_in_progress was still 1 — but a BGSAVE stays in_progress through the
RDB flush/fsync/rename tail after every key is serialized, during which
processed sits frozen at N/N. On a large save over a slow disk that tail can
exceed the stall window and trip a false "CRITICAL: appears stuck (processed
N/N keys)".

Only treat frozen progress as a stall while keys remain (processed < total);
when total is unknown (older servers without current_save_keys_total) keep the
prior elapsed-only behavior. A genuine hang in the tail is still caught by the
elapsed-time ceiling, which reports the (accurate) duration message instead of
"stuck / no progress".

Tests: a completed save lingering in its tail past the stall window fires
nothing; a tail hang past the crit ceiling still fires 'exceeded'.

…known

Bugbot follow-up on #294. The progressIncomplete guard was
`total === null || processed < total`, so a missing current_save_keys_total
made it true and frozen-progress CRITICALs still fired — contradicting the
adjacent comment, which said unknown totals should rely only on the elapsed
thresholds.

Without a total we can't distinguish the completion tail (processed frozen at
N/N) from a genuine stall, so raising a "stuck" CRITICAL is unsubstantiated.
Require the total to be known (`total !== null && processed < total`); when it's
absent, frozen-progress detection is skipped and the elapsed-time ceiling still
covers a real hang.

Adds a test: frozen processed past the stall window with no total reports
nothing.