TSA-147: Allow a page to be confirmed again after undo

[MatiStb]

Closes #147
Related to #56
Related to #266
Frontend consumer: #267
Offline queue scope: #143

Summary

Implements the backend support required to confirm a page again after it has been undone.

The verification history now distinguishes a genuine replay from a new verification attempt after undo.

What Changed

• Added page_event.attempt with a default value of 0.
• Updated page_event_once to include:
  • page_id
  • transcription_id
  • event
  • attempt
• Added append-only undo events to the page history.
• Added server-side attempt tracking for verification events.
• Made the undo operation transactional.
• Added the authenticated POST /api/v1/pages/:id/undo endpoint.
• Undo now:
  • returns the page to transcribed;
  • preserves the current transcription;
  • clears verified_by and verified_at;
  • moves the document cursor back to the undone page;
  • reopens a done document as processing;
  • leaves lexicon counters unchanged.
• Verification after undo uses the next attempt and is accepted normally.
• Exact verification replays remain idempotent and return 200 without creating duplicate events.
• Added the shared undo route and response DTO.
• Updated the database schema and verification/API documentation.
• Kept the offline queue implementation out of scope because it belongs to [FE] Offline queue for verification actions #143.

Acceptance Criteria

• Confirming, undoing, and confirming again leaves the page confirmed.
• Duplicate verification requests are absorbed without duplicating history.
• Undo moves the cursor back to the undone page.
• Reconfirmation advances the cursor again.
• Undo records an append-only undo event.
• Lexicon counters are not changed by undo or reconfirmation.
• Ownership and invalid page states are validated.
• The endpoint is available in production and protected by authentication.

Validation

Static Validation

The following checks passed:

• npm run lint
• Backend TypeScript typecheck
• Shared package TypeScript typecheck
• ESLint
• Prettier
• EditorConfig
• ls-lint
• Knip
• Backend production compilation with tsc
• Backend path replacement with tsc-alias
• git diff --check

Database Validation

Executed:

npm run migrate:dev -w apps/backend

Result:

Already up to date

Manual API Validation

The flow was tested against the running backend with PostgreSQL, Redis, and MinIO:

1. Confirmed a transcribed page.
2. Executed undo.
3. Confirmed the same page again.
4. Replayed the same confirmation request.
5. Verified the persisted event history.

Expected and observed history:

confirm | attempt 0
undo    | attempt 1
confirm | attempt 1

The final page state was:

confirmed

The replay returned 200 and did not create a duplicate event.

Additional manual checks:

• Swagger responded with 200.
• The undo route was registered by the backend.
• An unauthenticated undo request returned 401.
• An invalid token returned 401.
• An authenticated request for a nonexistent page returned 404.
• The cursor moved back after undo and advanced again after reconfirmation.
• The transcription remained intact after undo.
• The temporary test user and fixture data were restored after testing.

Related Work

• As an Authenticated User, I want to undo my last verification so that a slip does not cost me the page #56: Parent user story for undoing the last verification.
• [BE] Undo the last verification of a page #266: Backend undo functionality.
• [FE] Undo the last verification with Ctrl+Z #267: Frontend Ctrl+Z integration.
• [FE] Offline queue for verification actions #143: Offline verification queue, intentionally outside the scope of this PR.

[anjoanka]

Tested locally.
What works as described:

• confirm -> undo -> confirm leaves the page confirmed; the page_event history is confirm 0 / undo 1 / confirm 1.
• Replaying the same confirm returns 200 and doesn't create a duplicate event.
• Undo returns the page to transcribed, clears verified_by/verified_at and moves the cursor back to the undone page; re-confirming moves it forward again.
• Undoing a page that isn't verified -> 409, unknown page -> 404, no token -> 401.

Not covered in my testing: lexicon counters, reopening a done document, offline scenarios.

Three things worth discussing are in the inline comments (undo of an older page, a stale duplicate undo, and the down migration).