QA: concurrent-editor (2nd-user) presence warning + presence-route authz

[henrique221]

Context

By design there is no real-time collaborative editor; concurrent editing is
allowed and last-write-wins on verse saves is expected (field requirement). The
only guard is the presence warning banner shown to the 2nd+ user. The wiring
already exists: fluent-web useChapterPresence.ts → store presenceWarning →
header banner; API chapter-assignments/{id}/presence.

Scope (verify, fix only if needed)

1. QA the banner fires for the 2nd user within one heartbeat, and clears when
   the first leaves (DELETE on unload).
2. First-editor race — upsertAndQueryFirstEditor isn't serialized; if QA
   shows flakiness, use a stronger isolation level / SELECT … FOR UPDATE.
3. Presence-route authz (recommended) — presence routes skip
   requireChapterAssignmentAccess, so any translator can probe presence for any
   chapterAssignmentId (leaks editor identity across assignments). Align with
   the editor-state routes' requireChapterAssignmentAccess(IS_PARTICIPANT).

Decision (Kasey, 2026-06-18)

There is a warning that should display to the 2nd+ user to access the drafting
page of a chapter.

Refs

Follow-up from the security/export audit (#194, PR #189).
Detail: docs/proposals/security-and-export-hardening/04-concurrent-editor-warning-qa.md.

[henrique221]

QA result: ✅ the 2nd-editor warning works end-to-end

Verified live against the compose stack (API + worker + seeded DB) with the fluent-web dev server, using two translator accounts on the same chapter assignment (GEN 1, drafter translator + peer checker translator2).

Scenario & results:

1. Banner appears for the 2nd editor — with translator2 holding presence (30s heartbeats via POST /chapter-assignments/1/presence), translator opened the drafting page from the My Work dashboard → the yellow header banner "⚠ translator2 is editing this resource." appeared within seconds (the page's initial heartbeat). Screenshot captured.
2. Banner clears when the other editor leaves — translator2 sent the presence DELETE → the banner cleared on translator's next 30s heartbeat. Screenshot captured.
3. Unmount cleanup works — navigating away from the drafting page removed the editor's active_chapter_editors row (the beforeunload/cleanup DELETE fired), observed directly in the DB.
4. Authz (fix(presence): require participation + serialize first-editor check (#197) #202) — participant heartbeats 200/204; non-participant 404 was verified in PR fix(presence): require participation + serialize first-editor check (#197) #202.
5. First-editor ordering — deterministic across repeated registrations (the fix(presence): require participation + serialize first-editor check (#197) #202 advisory lock + tiebreaker); no flakiness observed, so the "if QA shows flakiness" contingency is settled.

One finding worth knowing (by design, but now explicit): presence — and therefore the banner — is only active when the chapter is in a check phase (community_review / linguist_check / theological_check / consultant_check); see the gate in fluent-web DraftingPage.tsx (useChapterPresence(..., isCommunityReview || isLinguistCheck || isTheologicalCheck || isConsultantCheck)). Two users on a chapter in not_started/draft get no warning. That matches the original intent ("we do not block a user from editing past the drafting phase… a warning should display to the 2nd+ user"), since only the drafter is expected during drafting — flagging it here so it's a documented decision rather than a surprise.

Screenshots (local, can be attached on request): banner visible on the 2nd editor's screen, and cleared after the first editor left.

All items on this ticket are now done — closing.