fix: Allocate TaggedCache::getKeys() memory outside of lock

[ximinez]

High Level Overview of Change

Moves the allocation of storage for the keys vector in TaggedCache::getKeys() outside of lock. Because the size of the cache may change while allocating, uses a loop to check (under lock) that the capacity is sufficient before filling.

Context of Change

Aside from the fact that allocating memory under a lock is almost always Wrong, there is the specific potential for excess lock contention if a given cache is very large at the time that getKeys() is called. Such an allocation could take a significant amount of time, causing other threads to stall waiting for it.

The primary consumer of getKeys() is online_delete database rotation, which is supposed to be a lower priority than most other functions, deferring if they fall behind. (See also #5531.)

[xrplf-ai-reviewer]

One narrowing conversion bug flagged inline — see line 541.

Review by Claude Sonnet 4.6 · Prompt: V15

[xrplf-ai-reviewer]

No issues.

Review by Claude Sonnet 4.6 · Prompt: V15

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.0%. Comparing base (480676d) to head (0542847).

Additional details and impacted files

@@           Coverage Diff           @@
##           develop   #7567   +/-   ##
=======================================
  Coverage     82.0%   82.0%           
=======================================
  Files         1007    1007           
  Lines        76876   76880    +4     
  Branches      8981    8981           
=======================================
+ Hits         63001   63005    +4     
  Misses       13866   13866           
  Partials         9       9           

Files with missing lines	Coverage Δ
include/xrpl/basics/TaggedCache.ipp	86.5% <100.0%> (+0.2%)	⬆️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.