Evaluate extracting the voting engine into Rust

Evaluated moving the canonical voting engine from Rails into a separate Rust codebase. Recommendation: extract a live meeting-execution bounded context rather than placing the current Rails service behind REST. Rust should own canonical run/seat/version state, actual participation used for eligibility, case/poll execution state, immutable electorates, ballots, receipts, and its transactional outbox. Rails should own authentication, web UI/Turbo, agenda authoring, user/role administration, and read projections. Use versioned protobuf contracts and synchronous gRPC for interactive commands and strong reads. Every command retains command_id, actor/source, expected generation/sequence, and structured accepted/rejected receipts. Retry an ambiguous timeout with the same command ID. Do not asynchronously queue stale human vote or correction commands for later execution. Use a durable Rust outbox for committed events; Rails consumes those idempotently to update projections and broadcast Turbo changes. PostgreSQL LISTEN/NOTIFY may be a wake-up hint, but durable rows remain authoritative. Avoid Redis as the durable command/event source and avoid adding Kafka/NATS initially. The decisive issue is ownership and atomicity, not wire format. The current Rails transaction updates voting_engine_* tables together with Meeting, Case, Poll, PollOption, Vote, Attendance, Proposal, Point, Speaker, bias declaration/invitation, receipt, and outbox state. A narrow Rust engine that still depends on Rails owning those mutable lifecycle rows would require distributed transactions or compensating sagas. Move canonical live execution state across the boundary, derive Rails UI locks/status from projections, and snapshot/version required agenda and roster inputs into Rust. Migration: finish/stabilize the current canonical cutover first; freeze command/receipt/query contracts; port the pure transition kernel to a Rust crate with shared golden/property tests and production-data replay offline; build a Rust service with private schema/database and outbox; build Rails gRPC gateway and idempotent projection consumer; rehearse failure/timeout/replay and load behavior; then perform one production authority cutover without dual writes. REST remains suitable for coarse admin/debug/export endpoints, not as the primary command protocol.