[fix][broker] Run the message expiry check off the topic policy update path

[lhotari]

Main Issue: #26037

Motivation

When topic policies are applied (PersistentTopic.onUpdate / onPoliciesUpdate → applyUpdatedTopicPolicies),
the message-expiry check (checkMessageExpiry) was run inline on the calling thread. That check can block: it
walks subscription cursors and can wait on metadata operations
(...getNthEntry → counter.await(metadataOperationsTimeoutSeconds), default 60s).

For topic-policy updates this inline work runs on the single, process-wide shared
broker-client-shared-internal-executor reader thread (the thread reported in #26037), so a single topic whose
oldest ledger is temporarily inaccessible could block topic-policy loading/updates. The check was also executed
on every policy update, even when the message TTL had not changed.

Modifications

• applyUpdatedTopicPolicies no longer runs checkMessageExpiry inline. Instead,
  maybeCheckMessageExpiryOnPolicyUpdateInBackground schedules it on the dedicated messageExpiryMonitor
  thread — the same thread the periodic expiry check already uses — so it never blocks applying or loading
  topic policies. The check is idempotent and the periodic monitor still provides eventual coverage, so it is
  no longer part of the futures returned by applyUpdatedTopicPolicies (callers no longer wait for it).
• The check now runs only when the effective message TTL actually changed since the last run (tracked via a
  new volatile int lastMessageTtlInSeconds), avoiding redundant scans on unrelated policy updates.
• Exposed BrokerService.messageExpiryMonitor via @Getter so the topic can schedule on it.

Verifying this change

This change is already covered by existing tests:

• MessageTTLTest — testTTLPoliciesUpdate was updated to wait for the now-asynchronous expiry check using
  Mockito timeout verification (the previous synchronous verify(times(N)) would otherwise race the
  background execution).
• PersistentMessageExpiryMonitorMockTest.

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

• The threading model

The message-expiry check triggered by a topic-policy update now runs asynchronously on the
messageExpiryMonitor thread instead of synchronously on the policy-application thread.