Pin down the condition that stops EditorApplication.delayCall (unfocused window observed in #3171) and update the comments #3174

Summary

While measuring #3171, EditorApplication.delayCall did not run at all while the Editor window was unfocused, in two separate processes, and ran 152 ms after the window gained focus. The code comments currently attribute the delayCall stall to the cold-start "Scripts have compiler errors" dialog only. This issue is for pinning down the condition and updating the explanations.

Observed (macOS, Unity 2022.3.62f3, UTC 2026-10-06)

Probe: register one delayCall, one self-removing update handler, and one dispatcher continuation; each writes a timestamp file.

• Process 1 (launched about 10.5 h earlier, never focused since): update and dispatcher files appeared within ~1 s; no delayCall file after 17 s and 61 s. At 68 s the delayCall file appeared, 152 ms after the first external_scene_focus_changed isFocused=true in the tool's debug log since launch. The pending setup-wizard show from startup ran at the same moment (it recorded the last-seen version in the user settings file).
• Same process, after it lost focus again: a new probe saw update and dispatcher within ~1 s, no delayCall after 12 s. One focus does not change the behaviour permanently.
• Process 2 (uloop launch -r, cold start, no compiler-errors dialog, zero focus events): update and dispatcher within ~1 s, no delayCall after 15 s.

Details and the probe snippet are in the description of #3171.

What this does not establish

• Not compared with a focused fresh Editor, another platform, or Unity 6. "Unfocused window" is an observation in this environment, not a rule.
• Whether the compiler-errors-dialog case recorded in the code comments is the same condition (an Editor that lost focus to the dialog and never got it back) or a different one.

Tasks

• Reproduce with the same probe on Unity 6000.x and on Windows, focused and unfocused, and record the result here.
• Check the dialog case against the focus explanation: trigger the dialog at cold start, dismiss it, focus the window, and see whether delayCall resumes.
• Update the comments that attribute the stall to the dialog alone once the condition is known. Sites on main today (git grep -n -i delayCall -- Packages/src Assets/Tests): SetupWizardWindow.cs (~60), SetupWizardStartupFlow.cs (~191), HotReloadEditorStartup.cs, WatchEditorStartup.cs, PausePointEditorStartup.cs, and the test comments in OnionAssemblyDependencyTests.cs (~888, ~910) and SetupWizardWindowTests.cs (~218). No page under docs/ mentions delayCall today.
• Decide whether docs/ needs a short page on "what runs in a backgrounded Editor" (update and the dispatcher do; delayCall may not), so that future code does not reach for delayCall again.