fix(restore): resume follow mode when saved TXID is ahead of latest s…

[atmin]

Description

Follow-mode crash-recovery resume validated the saved -txid against the latest snapshot's MaxTXID and refused to resume when the saved TXID was greater. Compare against the newest TXID across all levels instead, so a follow file that is ahead of the last snapshot but still backed by existing deltas resumes correctly. A stale/foreign -txid past all replicated data is still rejected; the "behind the earliest snapshot" check is unchanged.

Motivation and Context

A live follow file continuously applies level-0 deltas past the latest snapshot, while snapshots are only written every SnapshotInterval (default 24h). So the saved -txid is almost always ahead of the last snapshot, and resume was rejected in the normal case — including litestream restore -follow crash recovery — forcing a full re-restore instead of an incremental catch-up.

How Has This Been Tested?

New regression test TestReplica_Restore_Follow_ResumeAheadOfSnapshot (fails before this change with saved TXID … is ahead of latest snapshot, passes after):

go test -race -run 'TestReplica_Restore_Follow' .

All pass locally (full race suite green across all packages; go fmt, go vet, goimports, staticcheck on the changed files clean).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (would cause existing functionality to not work as expected)

Checklist

• My code follows the code style of this project (go fmt, go vet)
• I have tested my changes (go test ./...)
• I have updated the documentation accordingly (if needed)