Guard Rails lifecycle changes around Rust voting runs

Outcome Prevent meeting, case and source lifecycle changes from stranding an open Rust run or making retained Rust history unreadable. Confirmed gaps - Case end/reset controllers guard an active run, but Meeting#end!, scheduled meeting end, meeting reset and destruction do not query or transition Rust voting state. - A forced/automatic meeting end can therefore leave an authoritative Rust run open while Rails closes cases and voting rights. - Rust history stores proposal/point IDs while PollView requires those Rails rows to exist. Meeting/case/proposal/point deletion or destructive reset can orphan history; only selected proposal UI paths currently check Rust history. - Rails source reconciliation and Rust commands span two databases, so lost responses and lifecycle retries need explicit idempotent policy at every destructive boundary. Acceptance criteria - Manual, Cloud Router, scheduled and forced meeting end/reset/destroy paths fail closed while a run is open, or perform one explicitly defined idempotent Rust terminal transition before changing Rails lifecycle state. - Case reopen/archive/reset and proposal/point update/delete rules preserve immutable Rust history and source readability; destructive operations are blocked or retain a deliberate tombstone/display snapshot. - A terminal Rust run and Rails source/lock state reconcile after timeout, lost response, process restart and reload without duplicate bias or notification effects. - No ended meeting/case retains an unexplained open run, and no retained run becomes unreadable because a referenced Rails source disappeared. - Separate-connection race tests cover meeting end/reset, case transitions, source deletion/edit and Rust start/close/cancel responses; authenticated browser coverage exercises the secretary recovery path.