fix(managed-ledger): handle stale backlog after trimmed ledgers

[ShuKe-code]

Motivation

When an inactive durable subscription is deleted and later recreated(or first creation) with SubscriptionInitialPosition.Earliest, backlog can be reported incorrectly if historical ledgers have already been trimmed and only an empty current ledger remains.

In this case, getFirstPositionAndCounter() may derive the initial counter from a synthetic earliest position that points to a trimmed ledger range. As a result:

• approximate backlog can stay greater than 0
• precise backlog is 0
• no messages can actually be consumed
• unloading the topic clears the stale in-memory backlog state

Changes

• handle the synthetic earliest-position case in ManagedLedgerImpl#getFirstPositionAndCounter()
• return the current lastConfirmedEntry and entriesAddedCounter when historical ledgers are already trimmed and only an empty current ledger remains
• add a regression test covering earliest cursor recreation after ledger trim

Result

After the fix, recreating a durable subscription with Earliest in this scenario no longer reports stale backlog. Approximate backlog and precise backlog remain consistent.

Testing

• added ManagedLedgerTest#testEarliestCursorAfterTrimmedLedgersUsesCurrentEntriesAddedCounter

issues

#25813