Rejoin: recognise existing backups + add backup-freshness/viability state for logical/physical-backup rejoin

[svaroqui]

Summary

Operator rejoin via logical-backup / physical-backup — and the per-method availability shown in the Last Divergence viewer — is gated on HasBackupLogical / HasBackupPhysical (the WARN0111 / WARN0112 states). Two gaps make that signal unreliable for rejoin decisions:

1. Detection false-negative. WARN0111 "Cluster does not have logical backup" (and WARN0112 for physical) can be raised even when a repman-recorded backup actually exists, with its binlog file/position and GTID already captured in the backup metadata. The HasBackupLogical/HasBackupPhysical check (cluster_has.go) does not recognise the existing recorded backup.

2. No freshness / viability state. A backup can be present but too old (behind the elected master's current binlog) or on a diverged timeline — restoring it would not produce a valid rejoin. Nothing tracks this today ("no state on this").

Proposal

• Fix HasBackupLogical / HasBackupPhysical to recognise recorded backups (the metadata already stores the backup's binlog file/pos + GTID).
• Add a backup-freshness state: compare the backup's captured GTID / binlog position against the elected master's current binlog position, and raise a WARN when the backup is too old, or on a diverged timeline, to be usable for a rejoin reseed. All inputs (backup GTID/pos, master position) are already available.
• Reflect freshness in RejoinMethodsStatus so the operator is not offered — or is at least warned about — a logical-backup/physical-backup rejoin that cannot actually reseed cleanly.
• Verify the rejoin reseed selects the elected master's backup, not the diverged old master's split-time dump — restoring the latter would re-introduce the divergence.

Notes

Follow-up to the operator manual-rejoin work; not a blocker for the current release.