Optimize RedeliveryCount Handling Mechanism

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.

### Motivation

### **Description**

Currently, the message redelivery count (RedeliveryCount) only increases when the client actively calls the redeliver method https://github.com/apache/pulsar/issues/18239. However, in certain scenarios—such as when the program runs out of memory or crashes due to an unhandled exception—the message is not properly redelivered, and the count does not increase.

This can lead to messages being retried indefinitely without entering the dead-letter queue (DLQ), affecting system stability and failure recovery.

### Optimization Proposal

It is recommended to move the logic for increasing RedeliveryCount from the client to the Broker side to ensure:

- When a message is consumed but not acknowledged (due to process crashes or other issues), the Broker correctly increments RedeliveryCount.
- Messages reach the dead-letter queue (DLQ) in a timely manner after exceeding the maximum retry limit, preventing infinite retries.

### Solution

- Broker detects consumer disconnection and proactively increments RedeliveryCount.
- Client increases RedeliveryCount when receiving a message.

### Alternatives

_No response_

### Anything else?

_No response_

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

Start by tracing the broker's consumer-disconnection handling and the client's redelivery path, including the redeliver method. Determine how unacknowledged messages should update RedeliveryCount after a crash or disconnect and how that interacts with DLQ limits. Done means the broker and client behavior is defined and messages reach the DLQ after the configured retry limit without infinite redelivery.

Written by the indexing model from the issue text.