[fix][test] Isolate mutable broker fixtures between test methods

[lhotari]

Motivation

Several broker tests share mutable configuration and topic metadata across methods. A dispatch-metrics test leaves rate limits enabled before another method expects unlimited permits. Auto-topic-creation tests retain topics, partitioned-topic metadata, and configuration even though later methods assert exact namespace counts and default behavior. The TLS client-configuration test also leaves the shared broker configured differently for the next method. These leaks cause order-dependent failures when the methods run together.

Modifications

• Give BrokerDispatchRateLimiterTest and BrokerServiceAutoTopicCreationTest a fresh broker fixture for each method.
• Remove the redundant namespace-policy cleanup callback, since full fixture cleanup also resets configuration and metadata.
• Restore BrokerServiceTest's fixture in a finally block after the TLS client-configuration test, and close its local client with try-with-resources.

Existing assertions, asynchronous waits, and timeouts are preserved.

Verifying this change

• Make sure that the change passes the CI checks.

This change is covered by both complete BrokerDispatchRateLimiterTest and BrokerServiceAutoTopicCreationTest classes, plus BrokerServiceTest.testTlsWithAuthParams and testTopicFailureShouldNotHaveDeadLock.

• Temporarily repeated six affected methods with invocationCount=10: 84 test invocations passed, with retries disabled and no skipped tests.
• Removed the temporary repetitions and reran the same selection: 30 tests passed, with retries disabled and no skipped tests.
• ./gradlew spotlessCheck checkstyleMain checkstyleTest passed across all modules.

Both test runs used one test fork and TestNG preserveOrder=true / groupByInstances=true. Local review confirmed that assertions and existing waits remain intact.

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