kafka: make topic manager shutdown interrupt in-flight metadata refresh

What problem does this issue track?

The Kafka topic manager refreshes partition metadata every ten minutes. Its background goroutine calls AdminClient.GetTopicsPartitionsNum, which does not accept a context and eventually calls Sarama Client.Partitions.

PR #6081 briefly added a WaitGroup and made TopicManager.Close cancel the background context and wait for the goroutine. That ordering can delay sink shutdown when a refresh is already in progress:

1. The background goroutine enters GetTopicsPartitionsNum.
2. Kafka is slow or unavailable, so the Sarama metadata request blocks.
3. TopicManager.Close cancels its context and waits for the goroutine.
4. The in-flight metadata call cannot observe that context.
5. The admin client that could close the Sarama client is closed only after TopicManager.Close returns.

The wait can therefore last until the Kafka metadata request returns or reaches its configured timeout. With many topics, normal refresh work can also make shutdown latency proportional to the topic count.

The WaitGroup change is being reverted from PR #6081 so that the topic-visibility fix does not introduce this shutdown regression. The existing cancel-only behavior still does not guarantee that the background goroutine has exited before the admin client is released, so the complete lifecycle fix belongs in a separate change.

Expected behavior

Kafka sink shutdown should follow an explicit lifecycle:

1. Stop scheduling new topic metadata refreshes.
2. Interrupt or unblock an in-flight Kafka metadata request.
3. Wait for the topic-manager background goroutine to exit.
4. Release the remaining sink resources.

The component that owns the admin client should also own this shutdown ordering. Cancellation, client ownership, and waiting should not depend on an implicit call order between unrelated Close methods.

Suggested implementation direction

• Split topic-manager shutdown into a non-blocking stop/cancel phase and a wait phase, or make the metadata API genuinely context-aware down to the operation that can interrupt Sarama IO.
• Close the dedicated admin client between stop and wait so an in-flight Partitions call can return.
• Keep stop and close operations idempotent.
• Avoid adding a wait before there is a path that can interrupt the operation being waited on.

Acceptance criteria

• Add a deterministic test with a fake admin client whose metadata call blocks until the client is closed.
• Assert the shutdown order is stop topic refresh, close admin client, then wait for topic-manager exit.
• Assert sink/component shutdown returns after the blocked metadata call is released.
• Run the affected Kafka sink and topic-manager tests with the race detector.

Related to #6076 and #6081.

Locate TopicManager, its owning Kafka sink component, and the AdminClient.GetTopicsPartitionsNum path through Sarama Client.Partitions. Read the affected topic-manager and Kafka sink tests first, then add the blocking fake-admin-client test described in the acceptance criteria. Done means shutdown stops refreshes, closes the admin client, waits for the goroutine, and passes the affected tests with the race detector.