[br] BR backup retry can publish SST files from a replaced source cluster

## Bug Report

> Evidence status: confirmed.

### 1. Minimal reproduce step (Required)

Start a checkpoint-enabled backup of cluster A to a storage prefix and interrupt it after at least one range is checkpointed. Replace the PD/TiKV cluster with cluster B behind the same configured PD addresses, retain the prefix, and retry the same BR command. Inspect the retry BackupTS, incomplete-range set, and final backupmeta data files.

### 2. What did you expect to see? (Required)

Checkpoint metadata is accepted only when its recorded source cluster identity matches the current PD cluster. A mismatch must fail before reusing BackupTS, ranges, checksums, or SST files.

### 3. What did you see instead? (Required)

CheckCheckpoint accepts the same config hash without a cluster identity check, GetTS reuses the old BackupTS, BuildProgressRangeTree reports zero incomplete current ranges, and the new backupmeta contains old-cluster.sst.

### 4. What is your TiDB version? (Required)

master 13282a8bd06b

Likely root cause and fix direction

CheckpointMetadataForBackup stores config hash and BackupTS but no actual PD cluster ID. The hash binds PD address strings rather than the cluster behind them. Retry therefore treats old range completion and SST files as current-lineage proof.

Start by tracing BR retry handling through CheckCheckpoint, GetTS, and BuildProgressRangeTree, then inspect CheckpointMetadataForBackup and the backupmeta data-file handling. Reproduce the interrupted backup and cluster replacement described in the issue; done means a source-cluster mismatch fails before reusing BackupTS, ranges, checksums, or old-cluster SST files.

Written by the indexing model from the issue text.