[fix](fe) Prevent stale recycle candidates from erasing new generations

[wenzhenghu]

What problem does this PR solve?

Issue Number: close #67303

Related PR: HYDCP#103

Problem Summary:

CatalogRecycleBin collects expired IDs under a read lock and erases them later under per-item write locks. During that gap, RECOVER -> DROP can recycle a new object generation with the same ID, allowing the stale candidate to erase the new generation and write an incorrect erase journal.

This change snapshots the recycle-info object and recycle timestamp with each candidate. Under the write lock, it verifies object identity, timestamp, and current expiration before any erase callback, removal, or journal entry. Database, table, and partition paths are all covered.

Static review confirmed that the per-item lock scope remains unchanged and that the change does not alter persisted metadata formats, public APIs, configuration, or upgrade behavior.

Release note

Fix CatalogRecycleBin to preserve newly recycled databases, tables, and partitions when an erase cycle holds a stale expired candidate.

Check List (For Author)

• Test

  • Regression test
  • Unit Test
    • ./run-fe-ut.sh --run org.apache.doris.catalog.CatalogRecycleBinTest (33 tests passed)
    • ./run-fe-ut.sh --run org.apache.doris.catalog.CatalogRecycleBinTest#testExpiredDatabaseSnapshotDoesNotEraseNewGeneration+testExpiredTableSnapshotDoesNotEraseNewGeneration+testExpiredPartitionSnapshotDoesNotEraseNewGeneration (3 tests passed)
    • mvn -pl fe-core checkstyle:check -DskipTests
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes. Stale expired candidates are skipped when the same ID has been recycled as a new generation.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[wenzhenghu]

run buildall