TSA-146: Queue verification actions so a fast Enter burst is never dropped

[anjoanka]

Closes #146

What

Verification actions (Enter / Correct / Skip / Save edit) now go into a per-document queue instead of being dropped while a request is in flight.

• Keypress → the action is queued and the cursor moves immediately (no visible wait).
• A single runner (processVerificationQueue) sends one verify at a time; the next action leaves the queue only after the previous response.
• The optimistic update (status, edited text, rollback entry) is applied in verifyPage.pending, i.e. when the action leaves the queue — so at most one request is outstanding and rollback holds one entry per document.
• On failure: the failed page is rolled back, the cursor returns to it, the rest of the queue for that document is discarded, and the user gets a notification listing the actions that were not applied.
• Removed the isVerifying guard from handleVerify and the disabled state from the Correct / Edit / Skip buttons.

Also fixed

• verifyPage.fulfilled no longer sets cursorPageNo from the server response — during a burst it would pull the cursor back several pages.
• loadPages.fulfilled no longer overwrites a page whose request is still in flight (a burst crossing the 5-page batch boundary would wipe its optimistic status).
• RollbackState now also stores the transcription text, so a failed save restores the original text. The ticket notes expected [FE] Editing mode on the verification screen #265 to add this, but [FE] Editing mode on the verification screen #265 was closed (TSA-265: Editing mode on the verification screen #312) without it, and the rollback logic is rewritten in this PR anyway.

Behaviour changes

• If saving an edit fails with 409, edit mode is not reopened automatically; the draft is shown under the text ("Your previous draft"), press E to edit again.
• Ctrl+Z while the queue is busy shows "Wait until the queued actions are saved, then undo" instead of being silently ignored.
• The "Save and next" button in edit mode is no longer disabled while a request is in flight ([FE] Editing mode on the verification screen #265 AC). The queue replaces that guard: saves are queued like any other verification action.

Not in scope

• Offline queue ([FE] Offline queue for verification actions #143): VerificationQueueItem carries documentId, so actions can be handed off from here later.

How to test

1. Open a document with ~10+ transcribed pages on the verification screen, DevTools → Network, filter verify.
2. Press Enter 10 times quickly → cursor advances 10 pages at once, 10 verify requests, all 200.
3. Set throttling to 3G, press Enter 5 times → requests go strictly one after another (Waterfall).
4. With 3G on, press Enter several times and stop the backend → cursor returns to the failed page, a toast lists the discarded pages, no further verify requests are sent.
5. Page strip after reload: pages before the failure are ✓, the rest are not.
6. With 3G on, press E, change the text, Ctrl+Enter, then stop the backend → cursor returns to that page and the original text is shown, not the edited one.