[br] CRR reuses an unbound resume checkpoint across replication lineages

## Bug Report

> Evidence status: confirmed.

### 1. Minimal reproduce step (Required)

Leave crr-checkpoint/resume-state.json with last_checkpoint=100 from lineage A; run CRR for lineage B with the same task name and downstream bucket while its current upstream checkpoint is 10; then read CRR status and the log-restore maximum recoverable checkpoint.

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

The service rejects or ignores state whose upstream cluster, task generation, and storage lineage cannot be matched; any published recoverable checkpoint is at most the current lineage checkpoint.

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

The calculator returns 100 without listing metadata or checking objects, and getMaxRecoverableCheckpointFromStorage prefers 100 over the current storage checkpoint 10.

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

master 13282a8bd06b

Likely root cause and fix direction

PersistentState stores only LastCheckpoint, SyncedTS, and SyncedByStore at one fixed downstream path; RestorePersistentState accepts it without binding it to upstream cluster/task generation/storage identity.

Start with the CRR calculator, RestorePersistentState, PersistentState, and getMaxRecoverableCheckpointFromStorage, using crr-checkpoint/resume-state.json and the reproduction checkpoints 100 and 10 as the test scenario. Trace how state is restored and how the maximum is selected; done means mismatched upstream cluster, task generation, or storage lineage is rejected or ignored and the published checkpoint cannot exceed the current lineage checkpoint.

Written by the indexing model from the issue text.