There is a race condition in EnrichCoordinatorProxyAction that can result in an item being stuck in its queue even once all threads related to any schedule() calls have completed. The item will be flushed out on the next call to schedule() but there is no guarantee if or when that will happen. This PR adds an additional check for orphaned items in the queue.

Here's what I believe is happening (I can only reproduce it in fewer than 1 in 10,000 tries so I don't have direct evidence):

• Say thread # 1 calls schedule(), and then coordinateLookups(). It drains the whole queue, and comes through that while loop a second time and there's nothing there so it's about to call remoteRequestPermits.release()
• But while that happens thread # 2 is in schedule() and calls offer.
• So now thread # 1 still has the remoteRequestPermits lock and has decided there's nothing in the queue.
• So now thread # 2 comes into coordinateLookups() and gets false from remoteRequestPermits.tryAcquire() because thread # 1 still has the lock
• Now thread # 2 exists from coordinateLookups() and thread # 1 exits from coordinateLookups() but there's still 1 thing in the queue
• So now there's something in the queue that's just going to stick around until someone schedules something else.

(Note that there are actually more threads than just the 2 I mention since coordinateLookups() makes an async call back to itself)

Closes #90598