Refactor/rstest migration (#109)

* docs: Planifications

* chore: add rstest dev-dependency, derive PartialEq on InputAction

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* refactor: convert input.rs tests to rstest parameterization (42 -> 7 functions)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* refactor: convert theme.rs color roundtrip tests to rstest (7 -> 5 functions)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* chore: commit cargo lock

* refactor: convert db.rs tests to rstest fixtures + parameterize round-trips

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* refactor: convert signal/client.rs tests to rstest parameterization (39 -> 32 functions)

Parameterized: call messages, receipt variants, expiration variants,
sticker variants, and view-once variants. Added make_resp() helper to
reduce JsonRpcResponse boilerplate.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* refactor: convert app.rs tests to rstest fixtures + parameterization

- Convert test_app() to #[fixture] fn app() -> App
- Update all 114 tests from #[test] + test_app() to #[rstest] + fixture injection
- Parameterize 8 groups: resolve_mentions (4→1), bell_skipped (2→1),
  read_receipts (2→1), block_already_in_state (2→1), block_no_active (2→1),
  mouse_scroll (3→1), conversation_acceptance (2→1), group_menu_items (3→1),
  clears_attachment (2→1)
- 119 → 102 test functions, all 119 test cases preserved

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* docs: Include notes on testing in dev guid

* fix: remove plans

* refactor: split over-parameterized tests into separate functions

Five tests used string case labels with match/unreachable!() to dispatch
distinct setup logic, which obscures intent and conflates unrelated scenarios.
Split each into dedicated #[rstest] functions while keeping fixture injection.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix: lint

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Author: shwoop

.gitignore

@@ -5,5 +5,6 @@ Cargo.lock
 *~
 .DS_Store
 docs/book/
+docs/plans/
 signal-tui-debug.log
 .claude/settings.local.json

Cargo.lock

@@ -26,3 +26,6 @@ base64 = "0.22"
 arboard = "3"
 open = "5"
 notify-rust = "4"
+
+[dev-dependencies]
+rstest = "0.25"

Cargo.toml

@@ -23,6 +23,68 @@ Run a single test by name:
 cargo test test_name
 ```
 
+## rstest
+
+Tests use [rstest](https://docs.rs/rstest/) for fixtures and parameterization. The crate
+is declared in `[dev-dependencies]`.
+
+### Fixtures
+
+Two `#[fixture]` functions provide pre-built test objects:
+
+- **`app()`** in `app.rs` — returns an `App` with an in-memory DB and connected state.
+- **`db()`** in `db.rs` — returns an in-memory `Database`.
+
+To use a fixture, mark the test `#[rstest]` and add the fixture as a parameter:
+
+```rust
+#[rstest]
+fn my_test(mut app: App) {
+    app.input_buffer = "/quit".to_string();
+    // ...
+}
+```
+
+### Parameterized tests
+
+When multiple tests share the same assertion logic but differ in inputs, use
+`#[case]` to collapse them into a single function:
+
+```rust
+#[rstest]
+#[case("/quit", InputAction::Quit)]
+#[case("/q",    InputAction::Quit)]
+#[case("/help", InputAction::Help)]
+fn command_returns_expected_action(#[case] input: &str, #[case] expected: InputAction) {
+    assert_eq!(parse_input(input), expected);
+}
+```
+
+Each `#[case]` produces a separate entry in `cargo test` output, so individual
+failures are easy to identify.
+
+### When to use what
+
+| Situation | Approach |
+|---|---|
+| Test needs an `App` or `Database` | Use the fixture (`#[rstest]` + parameter) |
+| 3+ tests with identical structure, different data | Parameterize with `#[case]` |
+| 2 tests with significantly different setup | Keep them separate |
+| Test doesn't need a fixture | Plain `#[test]` is fine |
+
+### Best practices
+
+- **Prefer `#[case]` over copy-paste.** If you're writing a new test and an existing
+  parameterized test covers the same assertion pattern, add a `#[case]` instead of a
+  new function.
+- **Keep case data simple.** Strings, numbers, and booleans work well in `#[case]`
+  attributes. For complex types, build them inside the test body using a label parameter
+  and `match`.
+- **Add a `_label` parameter** when case data alone doesn't make the purpose obvious.
+  This shows up in test names (e.g., `my_test::case_basic`).
+- **Don't over-parameterize.** If merging tests requires a `match` with completely
+  different setup logic per arm, separate tests are clearer.
+
 ## Test modules
 
 Tests are defined as `#[cfg(test)] mod tests` blocks within each source file.