docs: note questions around ProduceResponse batch matching

Author: shan305

docs/producer-response-batch-matching.md

@@ -1,46 +1,20 @@
-\# Notes on ProduceResponse → ProducerBatch matching
+# Notes on ProduceResponse → ProducerBatch matching
 
+While reading `Sender.handleProduceResponse`, I wanted to write down a few questions
+before making any code changes.
 
+The response-to-batch lookup currently relies on:
+- topicId when present (newer protocol versions)
+- falling back to topic name + partition otherwise
+- a snapshot of topicId → name mapping taken before send
 
-While reading `Sender.handleProduceResponse`, I wanted to document and sanity-check
-
-one aspect of the response-to-batch matching logic.
-
-
-
-Currently, matching relies on:
-
-\- topicId when present (protocol v13+), but only if it can be resolved via a
-
-  topic-name snapshot captured before the request is sent
-
-\- otherwise falling back to topic name + partition
-
-
-
-Since metadata can change while a produce request is in flight
-
-(e.g. topic recreation, leader changes, protocol differences),
-
-I wanted to understand the guarantees around this mapping.
-
-
+Given that metadata can change while a produce request is in flight (topic recreation,
+leader changes, protocol differences), I wanted to confirm the guarantees here.
 
 In particular:
+- Are we assuming that a response with a non-zero topicId can always be resolved
+  using the topic-name snapshot taken before sending?
+- In what cases (if any) can `batch == null` occur, and is that considered an
+  impossible state or a deliberate hard failure?
 
-\- Are we assuming that a non-zero topicId in the response will always be
-
-  resolvable using the pre-send topic name snapshot?
-
-\- In what scenarios (if any) can `batch == null` occur here, and is that treated
-
-  as an impossible state or a deliberate hard failure to preserve correctness?
-
-
-
-No behavior change proposed yet , this note exists to clarify assumptions
-
-before exploring tests or hardening changes.
-
-
-
+This is just a note for now — no behavior change proposed yet.