Fire timer now does not advance a synchronous instance in the same request

"Fire timer now" runs its resume inside the engine batch context (WorkflowEngine::batch()), which holds the advance depth above zero. The inline drain that start() and signal() perform on a synchronous instance once committed is gated to depth zero (maybeDrainInline()), so it is suppressed for the fire.

Effect: on a synchronous instance, clicking "Fire timer now" resumes the waiting token but leaves the next step merely enqueued, so the run reads as a stall until cron, even though every other top-level operation on a synchronous instance advances in the same request.

Fix: after the fire batch unwinds, advance the instance in the same request when it runs synchronously, via a thin WorkflowEngine::drainSynchronous() wrapper over the existing depth-zero inline-drain guard. A queued instance is unchanged: it stays enqueued for cron, so the change aligns the operator UI with the instance execution mode rather than draining unconditionally.

Note: this is deliberately not "drain the advance queue like Run pending steps", which drains the global queue for every instance. The drain is scoped to the fired instance and gated on synchronous mode, so it never advances work a queued instance asked to defer. signal() and start() already drain synchronous instances this way at depth zero; only the on-demand fire was missing it because of the batch context.