fix: preserve critical replica lag when warnings are raised

[DivyamTalwar]

What and why

Addresses the remaining replica_lag_warn_seconds defect reported in #21. This does not close that umbrella audit.

A warning threshold above 300 seconds made the fixed critical threshold unreachable: with a configured warning of 600 seconds, a measured replay lag of 450 seconds produced no finding. Apply the configurable warning and fixed critical boundaries independently, preserving the existing WAL-flow and missing-measurement guards.

The finding documentation now states explicitly that increasing the warning threshold suppresses subcritical warnings, not the fixed critical boundary.

Verification

Verified commit: d49754f720c481cc3d6d10b3a1f640e4dfe55f95.

• New regressions fail on base a1e6561e366455756c45a16a46647f882b3b6a1c because raised warnings hide critical lag.
• go test -race ./internal/findings -run 'TestReplicaLagTime_' -count=20: passed.
• Boundary coverage includes warning values below, at and above 300 seconds, nil measurements, absent/idle WAL, and multiple critical replicas with the worst lag reported.
• bash scripts/gate.sh: passed on the committed HEAD, including pinned lint and all six release-target builds.
• go test -race ./...: passed; formatting and git diff --check are clean.
• PostgreSQL 18 collector/CLI integration and dependency scanning passed on the identical source tree in the fork validation run. Only author/message metadata differs in this commit.

Risk and rollback

Users with warning thresholds above the documented critical threshold will now see the critical finding that was previously hidden. Default thresholds, nil/idle handling and the JSON schema are unchanged. Revert this commit to restore prior behavior; no migrations or dependency changes are required.

Checklist

• Committed-HEAD gate, full race tests and formatting pass.
• Findings remain deterministic; read-only and privacy invariants are unchanged.
• Existing finding documentation updated; no new finding or JSON field added.