[fix][txn] Fix X-Pulsar-txn-uncommitted header semantics and add X-Pulsar-txn-consumable for peek messages

[poorbarcode]

Motivation

The X-Pulsar-txn-uncommitted response header returned by peekNthMessage / peekMessages REST APIs incorrectly indicates whether this specific entry's transaction is uncommitted. Currently it compares entry.position > maxReadPosition, which conflates two distinct concerns: the entry's own transaction state and the visibility of the entry (whether earlier uncommitted transactions block it).

Concretely, if transaction T1 is uncommitted and transaction T2 is committed, peeking T2's message still returns X-Pulsar-txn-uncommitted: true even though T2 itself is committed — the header is actually reporting that an earlier uncommitted transaction exists, not that this entry's transaction is uncommitted. This makes the header semantically misleading.

We need to:

• Correct X-Pulsar-txn-uncommitted to reflect this entry's own transaction state.
• Introduce a new header X-Pulsar-txn-consumable that reflects whether this entry can currently be consumed (i.e. no uncommitted transactions precede it).

Modifications

• Correct the value of X-Pulsar-txn-uncommitted
• Added X-Pulsar-txn-consumable header based on position <= maxReadPosition.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment