fix(store): estimate batch consume queue count up to max offset

[zjncs]

Motivation

estimateMessageCount translated the exclusive upper bound to with getBatchMsgIndexBuffer(to), which returns null when to equals maxOffsetInQueue. Every accumulation query that counts up to the queue head therefore hit the null branch and returned -1, and callers such as DefaultMessageStore silently fell back to the raw offset difference, ignoring batch sizes and tag filters.

Modifications

Since to is exclusive, look up the unit containing to - 1 instead, and advance physicalOffsetTo past that unit so the scan covers it. Interior ranges are unaffected because a to that lands on a batch base resolves to the same mapped position as before.

Verification

Fail-before (new test, run against the unpatched code):

Tests run: 6, Failures: 1, Errors: 0 -- BatchConsumeQueueTest#testEstimateMessageCount
java.lang.AssertionError: expected:<1000> but was:<-1>
  BatchConsumeQueueTest.testEstimateMessageCount:285 -- estimateMessageCount(1, 1001) with to == maxOffsetInQueue

Pass-after:

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 -- BatchConsumeQueueTest

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Summary

Fix estimateMessageCount in BatchConsumeQueue — the exclusive upper bound to was used directly as an offset, but getBatchMsgIndexBuffer returns null for offsets >= maxOffsetInQueue, causing counting up to the queue head to fail. Correctly uses to - 1 and adds CQ_STORE_UNIT_SIZE to get the physical end offset. Includes test coverage.

LGTM — focused fix with clear rationale in comments.

---

Automated review by github-manager-bot