tests-cargolisted

# Backend tests: cargo (Rust) Rust's test framework is built into the toolchain; there is no framework to detect. Check whether the project uses `rstest`, `proptest`, `insta` or `cargo-nextest` before writing — follow what is there rather than adding another. ## Two kinds of test, and only one of them is yours - **`tests/*.rs` — integration tests. Your lane.** Each file is compiled as its own crate and can use only the package's **public** API, which is exactly what an integration test should exercise. Shared helpers go in `tests/common/mod.rs` (a subdirectory module, not `tests/common.rs`, which would itself be collected as a test crate). - **Inline `#[cfg(test)] mod tests` — unit tests. Not your lane.** They live *inside* the production source file, so writing one means editing a file `tank` owns. A `.rs` file is shared by concern the way a Razor view is, and a file glob cannot see inside it. So: write the integration tests, and when a module needs unit-level coverage that only an inline test can reach (a private function, an internal invariant), **report that to `morpheus`** so it goes back to `tank` — don't restructure production code to make the test reachable from `tests/`, and don't make a private item public just so you can test it. Doc tests are a third kind: examples in `///` comments compile and run under `cargo test`. They live in the production file too, so the same split applies. ## Writing - `#[test]` functions return `()` or `Result<_, E>`; re