mir-backend-rust-actixlisted

# /mir-backend-rust-actix · Make It Right (Actix-web) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-rust` (Tokio runtime model) → **this** (Actix-web library mechanics). Run the gates first; load the Rust runtime tier for blocking/cancellation/Arc concerns; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (blocking the async runtime, cancellation safety, bounded channels, timeouts) live in `mir-backend-rust` — not here.** **Stack assumed:** Actix-web (4.x) · actix-rt (Tokio-backed single-threaded workers) · async Rust. ## The Actix-web footguns AI walks into most ### 1. The multi-worker App Data trap — the defining Actix footgun `HttpServer::new` accepts a **closure** (the App factory) and calls it **once per worker thread** (default: one worker per CPU core). Any state you **construct inside** the closure is created N times — yielding N completely independent copies. This is silent and compiles perfectly: there's no error, just N separate caches, N separate in-memory counters, or N separate connection pools that never coordinate. ```rust // WRONG — a fresh Vec is created for each of the N workers // Every worker has its own isolated list; requests are distributed // across workers, so the list appears empty or inconsistent HttpServer::new(|| { let state = web::Data::new(Mutex::new(Vec::<String>::new())); // N copies! App::new() .app_data(state) .route("/i