rust-asynclisted

# Rust Async `rust-patterns` has a brief Tokio snippet for the default idiom. This skill is for the actual pitfalls that produce real bugs in async code — lead with those, since they're why this skill exists separately from `rust-concurrency-sync` (OS threads). ## Mental model (needed to make sense of every pitfall below) - An `async fn`/block compiles to an anonymous type implementing `Future`, holding all its local state (including references between its own locals across `.await` points). - **Futures are inert.** Unlike a JS `Promise`, nothing happens — not even a timer starting — until an **executor** polls the future. Constructing a future and dropping it without `.await`ing or spawning it does nothing. - A **task** is a top-level future the executor schedules; tasks are cooperatively scheduled onto a pool of OS threads and are *not* 1:1 with threads — many tasks share one thread. Concurrency within a single task happens by polling multiple nested futures (e.g. via `select!`), corresponding loosely to nested calls. - Rust has no built-in runtime — you pick one (Tokio is the ecosystem default; `smol` for lightweight use). A **runtime** = an executor (runs futures) + a reactor (drives I/O). ## Pitfall 1: blocking the executor (silently serializes "concurrent" work) Most executors run tasks cooperatively on a limited thread pool. Any task that blocks its thread — a CPU-bound loop, or a **synchronous** blocking call — prevents the executor from polling eve