perf: optimise staking endblocker

[randy-cro]

Description

This PR optimises the staking endblocker.
It was discovered that on RocksDB archival nodes, the staking endblocker could take up to 1100ms, causing them to consistently lag behind pruned nodes. As such, there is an urgent need to improve block sync performance.

---

Root Cause

• Fetching the following iterators was slow:
  • ValidatorQueueIterator
  • UBDQueueIterator
  • RedelegationQueueIterator
• Each iterator took ~300ms to return, even when there were no entries, due to excessively large scan ranges.

---

Changes Made

• Cache unbonding validators, delegations and redelegations :
  Instead of scanning the database from the beginning of time to the latest block height or timestamp on every block, an in-memory cache now stores these entries, significantly reducing I/O. The iterator is invoked only once during cache initialization when the node starts.

---

Results

With telemetry metrics enabled, we observed a significant performance improvement after these optimisations were applied.

Before:

After:

Closes: #XXXX

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues. Your PR will not be merged unless you satisfy
all of these items.

I have...

• included the correct type prefix in the PR title, you can find examples of the prefixes below:
• confirmed ! in the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• reviewed "Files changed" and left comments if necessary
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• updated the relevant documentation or specification, including comments for documenting Go code
• confirmed all CI checks have passed

[thomas-nguy]

lgtm