[fix][broker] Skip backlog-quota eviction on fenced/closing topics

[lhotari]

Motivation

BrokerService.monitorBacklogQuota runs every backlogQuotaCheckIntervalInSeconds and iterates every persistent topic on the broker via forEachPersistentTopic (BrokerService.java:2476). For each topic it calls BacklogQuotaManager.handleExceededBacklogQuota, which mutates managed-ledger cursor state via slowestConsumer.skipEntries and markDeletePositionMoveForward (see BacklogQuotaManager.java:140-213).

Today this runs unconditionally — including on topics that have already been fenced (e.g. transient ledger-interceptor exception) or are closing/deleting (fenceTopicToCloseOrDelete() sets isClosingOrDeleting = true and isFenced = true).

When a namespace is being force-deleted under quota pressure, the checker concurrently mutates cursor state on a topic the delete path is trying to tear down. The two compete for the same managed-ledger / cursor, slowing the deletion. This was observed as intermittent Awaitility.deleteNamespace timeouts in BacklogQuotaManagerTest — see https://github.com/apache/pulsar/actions/runs/25387367872/job/74455105884 (PR #25676 attempt 1).

A test-side workaround for the symptom is in #25680; this PR addresses the underlying broker behavior.

Modifications

Early-return at the top of BacklogQuotaManager.handleExceededBacklogQuota if the topic reports isFenced() or isClosingOrDeleting():

if (persistentTopic.isFenced() || persistentTopic.isClosingOrDeleting()) {
    // entries are about to be discarded — running eviction is wasted work
    // and contends with the close/delete path
    return;
}

Both methods are auto-generated by Lombok @Getter on the existing fields (AbstractTopic.isFenced, PersistentTopic.isClosingOrDeleting). No new accessors needed.

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as BacklogQuotaManagerTest.testConsumerBacklogEvictionSizeQuotaCleansPendingAcks and BacklogQuotaManagerTest.testConsumerBacklogEvictionTimeQuotaNotPreciseCleansPendingAcks (the normal-path eviction is exercised; both pass locally with this change applied).

The skipped path (fenced/closing topic) is a correctness no-op: the entries to be evicted are about to be discarded anyway by the close/delete pipeline, so the only observable effect is the absence of redundant cursor mutations during teardown.

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

• 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