Queued undo/redo across async applies: gate on the typed answer, not on any state update

When a webview UI queues Undo/Redo presses that arrived during a reload, and replays them once the restore completes, don't advance the queue on every state/context message from the page. The apply is asynchronous, and unrelated updates (a debugger tick, a quiet edit, a marker move) can arrive before the answer to the previous op. Running the next queued op then pushes a stale view onto the redo stack. A probe showed it: two queued undos with an unrelated context in between, then Redo, Redo, Undo left 2 rows instead of 1. Fix: keep an in-flight flag, set it when an op is posted, and clear it (and run the next op) only on a context tagged as that op's Undo/Redo answer. Reset it on init/reload, and scope the queue to the file path so history from file A never applies to file B.