Serialize Rust voting starts with eligibility changes

Attendance, absence, ordinary invitation, upgrade, bias invitation, declaration and voting-right persistence now acquire the shared Rails meeting lock; bulk cross-meeting workflows lock meetings in stable ID order. Remaining Rust boundary gap A run start currently reads source/electorate state and calls Rust without holding that meeting lock. Participant switching checks Rust for an open run before its mutation acquires the lock and does not recheck under the lock. A concurrent eligibility change can therefore commit between the snapshot and Rust start, or proceed after a stale no-open-run check. Required outcome - Use one serialization protocol for every eligibility writer and Rust run start: after acquiring the shared meeting lock, fail closed on Rust read failure, recheck that no run is open, capture sources/electorate/casting voters, and keep the boundary serialized until Rust accepts or rejects start. - Do not add mid-run synchronization; a committed run keeps its frozen electorate. - Cover participant switch/back, roll-call application, reservation/assignment, bias/declaration effects and start against separate database connections and delayed/lost Rust responses. - Prove a change either completes before snapshot capture and is included, or waits until the run is terminal; it must never mutate eligibility during an open run.