Edit: With the new information and test case provided in the question, it's clear that this answer is incorrect (or at least inadequate). Clearly there are indeed additional input event queue(s) which do not get the opportunity to feed event-read while elisp is being actively executed, until some kind of waiting occurs.
Original answer follows...
If the event is already existing/pending, I don't think you need to deal with timeouts at all?
(let ((unread-command-events '(42)))
(read-event))
=> 42
An answer to another question suggests that supplying a timeout of zero to read-event (as the optional SECONDS parameter) will always return nil immediately
That's certainly not what I'm seeing in a cursory test:
(let ((unread-command-events '(1))
(unread-input-method-events '(2))
(unread-post-input-method-events '(3)))
(list (read-event nil nil 0)
(read-event nil nil 0)
(read-event nil nil 0)))
=> (3 1 2)