DatabaseProbe: distinguish "replica lost" from "no replica" in #1160

hasReplicaConfigured() (added in #1158 / "skip the replica rule when no replication is configured") treats an empty SHOW REPLICA STATUS/SHOW SLAVE STATUS
result and a failed query (e.g. missing REPLICATION CLIENT privilege, transient connection error) identically: both silently skip the Slave_lag rule.

That's fine for instances that never had a replica, but it also masks the case where a replica was previously detected and then stops being detected — which is itself a signal worth surfacing (replication broken badly enough to deregister, DB user privileges changed, failover happened, etc.), rather than quietly going quiet.

Proposed follow-up:

• Persist the last known Replica_configured state (per host/instance) alongside the existing snapshot data.
• If a probe previously saw a configured replica and a later probe can't confirm one (query fails or returns empty), report it as a failing/warning signal instead of SKIPPED.
• If a probe fails outright (exception, e.g. access denied) rather than returning an empty result, log it distinctly so an admin who wants the check knows to grant the missing privilege.