Build the Rust live-meeting runtime foundation

Built and integrated an in-repository Rust live-meeting runtime foundation without meeting business logic and without Docker/deployment changes. The repository has a pinned Cargo workspace and one production-shaped Axum/Tokio service under services/meeting_runtime. It uses Askama server-rendered HTML, shared Kaukus Tailwind assets, six-language locale files, PostgreSQL/SQLx migrations in an isolated meeting_runtime schema, explicit SQL, immutable accepted-command receipts with digest-based idempotency/collision rejection, and one transactional outbox event per accepted command. Health/liveness and readiness endpoints are included. Versioned PreparedMeeting.v1 and CompletedMeeting.v1 fixtures define the Rails-before/Rust-live/Rails-after boundary. The Rails client can prepare and activate meetings, Rust persists and renders the live dashboard, Rust completion redirects ownership back, and Rails fetches/validates/renders the completion package. A standalone development demonstration remains at /development/meeting-runtime. The normal meeting flow is now integrated behind an opt-in selector on the Rails meeting creation form. Rails remains the default; Rust is offered only when the runtime feature is enabled. Rust-selected meetings receive stable runtime, prepare-command and activate-command UUIDs. Starting one sends its real Rails actor, attendance roster, cases and proposals to Rust before the existing Rails start lifecycle. The first secretary-dashboard request idempotently activates Rust. Rails keeps the full live_meeting shell, top bar, sidebar, mobile navigation, modals and support controls while a single meeting_runtime_dashboard Turbo Frame owns the central content. Legacy secretary subtabs are hidden for that ongoing meeting. Rails-selected meetings retain the existing dashboard unchanged. Embedded mode hides the standalone foundation completion control; production completion/re-import remains future work. Development is fully repository-integrated: bin/dev starts assets, Sidekiq, Rails on KAUKUS_WEB_PORT (default 3000), and the watched Rust service on 3201 while preserving custom Procfile.dev content. The watcher uses Ruby standard library polling, rebuilds on source/template/locale/migration changes, and shuts down cleanly. bin/setup fetches Cargo dependencies; bin/meeting-runtime provides check/test/fmt/run; Gitea CI runs Rust formatting, Clippy and tests. No Docker or compose files changed. Terminal feedback mirrors Rails: compact Started/Completed HTTP lines include request UUID, method, path, status and duration; command logs show command/meeting/receipt/outbox identifiers, acceptance, replay and collisions; startup reports migration readiness. Rails outgoing calls log with [MeetingRuntime]. Validation passed: 5 Rust tests including real PostgreSQL round-trip, replay, collision rejection, receipts and outbox; 62 targeted Rails examples including legacy start regressions, model identifiers, creation selection, handoff snapshots, activation and Rails fallback; cargo fmt; Clippy with warnings denied; cargo doc; RuboCop on new files and changed code (excluding documented pre-existing cops in Meeting/MeetingsController); all six translations; migration rollback/reapply; shell/Ruby syntax; git diff check. Authenticated Chrome acceptance verified the real creation selector and a normal Rails live shell containing the embedded Rust dashboard with real Rails meeting title, case, proposal and participant; old secretary subtabs and completion control were absent; there were no Turbo/content/styling failures. An unrelated support-ticket poll returned 503 without affecting the runtime. Temporary acceptance data and servers were removed.