Avoid render-thread contention and lost worker notifications

[CH4ACKO3]

Posting a notification can block the render thread on the worker monitor, and a notification between checking the queue and waiting can be lost. Register workers and use park/unpark permits to avoid both races.

Verified: existing upstream :common:test suite.

[lap2ka]

Holy slop

[CH4ACKO3]

Holy slop

I understand general asynchronous programming concepts, though Java isn't part of my usual tech stack. Essentially, my workflow involves identifying an issue, having the AI ​​pinpoint and explain it in a language-agnostic way, and then proposing a fix for the AI ​​to implement.

Specifically, the issue here is a race condition regarding the queue state: consumers (worker threads) aim to process continuously until the queue is drained before waiting, while producers attempt to send notifications after submitting tasks. A gap exists where a notification sent between the moment a consumer determines the queue is drained and the moment it actually begins waiting gets lost, because the receiver isn't yet ready to wait. A viable fix is ​​to switch to the park/unpark methods provided by LockSupport. Since unpark retains a permit—effectively caching the fact that a notification occurred—a subsequent call to park returns immediately; this seems to me sufficient to resolve the problem.

It was an oversight on my part not to review the final PR before the automatic submission; the AI ​​introduced unnecessary tests while implementing the fix, creating extra overhead for the review process, and I apologize for that. The "Slop" part is decoupled and can be safely removed. However, given the constraints on human time and energy, the best I could do was offer a constructive proposal based on my level of expertise.

Thank you for the feedback, regardless.