Title: RequestReply can deadlock when duplicate reply events arrive

[rootp1]

Describe the bug

RequestReply can deadlock when duplicate reply events arrive for the same inflight request. The reply handler sends on pr.replyEvent while holding RLock(), while request cleanup needs the write lock to delete the inflight entry. If a second reply arrives before cleanup finishes, the second send can block and prevent cleanup from ever acquiring the write lock.

Expected behavior

Duplicate or late replies should be ignored or rejected without blocking inflight request cleanup. The handler should always clean up the inflight entry and return.

Actual behavior

The reply path can block while still holding the request-map read lock, and the original request path can then block indefinitely while trying to acquire the write lock for cleanup. The inflight entry remains uncleared and the request never completes normally.

To Reproduce

1. Create an inflight request entry in pkg/requestreply/ingress_handler.go.
2. Start handleNewEvent(...) so it waits on pr.replyEvent.
3. Deliver two valid reply events with the same reply correlation ID in quick succession.
4. Observe that one goroutine blocks on pr.replyEvent <- event while the original request path blocks on deleteEvent(...), leaving the inflight entry uncleared.

A focused unit test can reproduce this by exercising handleNewEvent(...) and handleReplyEvent(...) concurrently with the same reply ID.

Knative release version

main at repository state assessed on 2026-07-15

Additional context

Relevant code:

• pkg/requestreply/ingress_handler
• pkg/requestreply/ingress_handler