KAFKA-15038: Remove topicIdByPartitionMap from RemoteLogManager

[JiayaoS]

Remove topicIdByPartitionMap from RemoteLogManager and resolve topic IDs from the metadata cache for normal remote log operations. For stop-partition paths, pass TopicIdPartition through StopPartition so remote log cleanup can use the topic ID from the metadata image even when the current metadata cache no longer contains the topic.

[JiayaoS]

This revives and updates #20256 for KAFKA-15038. RemoteLogManager previously maintained its own topic ID cache, populated from leadership changes and cleared during stop-partition handling. That duplicated metadata state and could be missing during topic deletion or partition stop paths.

With this change, RemoteLogManager no longer owns a topic ID cache. Normal operations resolve topic IDs from the broker metadata cache. Stop-partition handling uses the TopicIdPartition supplied by the caller. This is important for KRaft topic deletion, where the metadata cache may already reflect the new image before ReplicaManager.applyDelta processes the delete delta. ReplicaManager now uses the previous metadata image topic ID when constructing StopPartition, allowing RemoteLogManager to clean up remote log state with the correct topic ID.

Tests:

• Added ReplicaManager coverage for topic deletion where the current metadata cache no longer contains the deleted topic ID.
• Added RemoteLogManager coverage to verify stopPartitions uses the TopicIdPartition supplied by StopPartition.
• Removed obsolete RemoteLogManager tests that validated topicIdByPartitionMap cache population/eviction and cache-based partition readiness, since RemoteLogManager no longer maintains that cache.
• Updated existing tests for the new StopPartition topic ID flow.

[github-actions]

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.