MicroVM worker: the unknown-outcome warning and its refusal are decided in two locked blocks #820

Summary

For an unknown outcome of the worker's own SuspendMicrovm call, the Python worker chooses the warning text and the 30-second refusal in two separate locked blocks. An event between them can make the logged text false.

Details

1. The decision block in _call_suspend reads _suspending under the lock, and chooses the warning text from it.
2. For an unknown outcome, that block changes no state.
3. The worker then releases the lock, writes the warning, and closes the client if it owns it.
4. A second locked block then reads _suspending again. It starts the 30-second refusal only if _suspending is still set.
5. A suspend hook's 30 seconds can end between the two reads. The grace timer then clears _suspending.
6. A review probe did this. The worker logged "The worker refuses jobs until the MicroVM resumes, or for 30 seconds." A job sent right after the warning got HTTP 202.
7. The behavior is correct: the hook's 30 seconds ended, so the worker accepts jobs. Only the log line is false.
8. The window lasts as long as the log write and client.close() take. That is a few milliseconds with a fast log sink.
9. The JavaScript worker has no such window. It logs, destroys the client, and checks suspending without an await in between.
10. The comment in the decision block says the text matches the decision. For an unknown outcome, the decision is in the second block. So the comment is true only for a rejection and a refusal for now.

The window existed on main before #817.

Proposed fix

For an unknown outcome, start the 30-second refusal inside the decision block when _suspending is set, and skip the second block for that outcome. The success path still needs the second block. The 30 seconds would then start before client.close() instead of after it.