Advance a synchronous run when an incident is retried, resumed or skipped

Fixes the incident resolutions that left a synchronous run standing still.

retryIncident(), resumeIncident() and skipIncident() each put a token back in play and then committed and returned, so on the shipped default execution mode the operator was told the incident was resolved and the run did not move until the next cron. The three now ask WorkflowExecutor::drainSynchronous() once their own transaction has committed, which is what signal(), spawn() and an on-demand timeout already do. cancelIncident() and failFromIncident() leave no active token, so neither drains.

The drain is in the engine rather than in a surface, so the instance page, the Resume form, the API and any third-party operator tool get it together.

IncidentSynchronousDrainTest pins no execution mode, so it runs the default a site gets out of the box, and makes every assertion with no queue drain after the operator acts. Three of its six cases fail against unpatched 1.x; the other three are controls that pass either way, including the queued run that must still wait for cron.