fix: reject BatchProofQueue ingress collisions and fix commit accounting

[0xIcarus]

Description

BatchProofQueue keys slots on (author, batch_id) without the content digest. Two batches sharing the same key but different metadata can corrupt a slot thus grafting a proof onto a mismatched summary or vice versa and cause a u64 underflow in mark_committed when num_txns diverges.

How Has This Been Tested?

4 regression tests in batch_proof_queue_test.rs covering: summary-first collision, proof-first collision, colliding summary on an existing proof, and the mark_committed underflow case. All 11 tests in the module pass.

Key Areas to Review

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[areshand]

could you next time include the upstream in the your PR description? if there is none, mention None. It would make the review much easier

[areshand]

as commented

[areshand]

Blocking: This fixes the counter decrement, but the colliding commit still leaves the queued item's BatchInfo and expiry indexes authoritative. I reproduced A(expiry 10) → colliding B(expiry 20) committed → advance to 10 → retransmit B; A's stale expiry removes the committed tombstone and B is accepted (remaining_proofs=1). Could we replace or synchronize item.info, author_to_batches, and expirations with the committed batch (or otherwise ignore stale expirations), and add this lifecycle regression? The current helper forces u64::MAX, so the existing tests cannot catch it.