UR5e replay refresh waits behind diagnostic file writes

Reads return promptly. File writes block the next update. Old value stays labelled current throughout.

Are recording gaps visible anywhere?

No. Developer is separating the writer and adding display age and recording-gap information.

Define what the writer does when it cannot keep up. The display may only need the latest diagnostic reading, but somebody reviewing a log needs to know which history was omitted. An ever-growing queue just postpones the stall. A bounded queue with explicit gaps can be useful for this diagnostic stream, provided nobody mistakes that file for a complete inspection-result record. Keep those purposes separate while you test the deliberately slow writer.

Bounded diagnostic queue tested. Slow writer no longer stalls refresh; omitted diagnostic entries are counted and marked.

And failed reads? Does the old value still pretend to be current?

Failure leaves last reading visibly stale with its age. Slow-write and failed-read replay checks pass after reopening too.

Keep both failure cases with the component tests. The replay monitor now has a measured fix for the blocked writer and honest information about its limits; a lively screen should not be taken as evidence of gap-free recording.