Expand input coverage with fuzzing

[moodmosaic]

Input coverage = how well we test the range of inputs, not just which lines or branches we hit. For example:

fn is_even(n: u32) -> bool {
    n % 2 == 0
}

Here, testing only n = 2 gives 100% line coverage but misses 0, 1, u32::MAX, etc. That’s low input coverage. We want to hit edge cases, boundaries, and weird values.

By pairing property-based testing (proptest via cargo test) with coverage-guided fuzzing (libFuzzer via cargo +nightly fuzz), we can explore code paths with broader, more meaningful input variation.

---

Specifics

Use of arbitrary

One approach is to use a shared arbitrary::Arbitrary model across both tools. This improves consistency and avoids duplication. But it should be documented, with pros (reuse, shared logic) and cons (higher discard rates, less fuzzing depth) made clear.

Use of mockall

These tools work best when tests run fast. Mock I/O, networking, etc, as needed. Use mockall to generate static mocks, and configure them per test using closures. For traits with associated types, wire them manually (example).

[moodmosaic]

Core

• Convert one pure unit test -> proptest.
  • feat: use clarity-serialization in clarity #6310 (review)
  • Ephemeral MARF #6365 (review)
• Convert one pure unit test -> libFuzzer target.
• Add a raw-bytes fuzz target (no Arbitrary) for malformed inputs.
• Extract a shared arbitrary::Arbitrary for proptest + fuzz; doc pros/cons.
• Mock externals with mockall; proptest + test the core logic.
  • moodmosaic@34f285d
• Mock externals with mockall; proptest + fuzz the core logic.

Optional

• Add a minimal state-machine property; fuzz its command runner.
• Add an AFL target (out-of-process) alongside libFuzzer.
• Note tuning tips: discard limits, shrinking, libFuzzer dictionary,
  other engine-specific options.