Update cargo-fuzz setup; split fuzz_value_sanitize so it runs

[moodmosaic]

This makes clarity/fuzz/ build and actually run on nightly. It also moves fuzz_value_sanitize into its own target so cargo-fuzz detects and runs it. Diff kept minimal.

Notes:

• This fixes compiler errors to keep Expand input coverage with fuzzing #6355 moving.
• I haven’t reviewed what these existing fuzz targets actually test. They’ve been in the repo for some time. I kept the diff minimal to get them compiling and running.

How to:

• List: cargo +nightly fuzz list
• Build all: cargo +nightly fuzz build
• Build one: cargo +nightly fuzz build fuzz_sanitize
• Build one: cargo +nightly fuzz build fuzz_value_sanitize
• Run: cargo +nightly fuzz run fuzz_sanitize
• Run: cargo +nightly fuzz run fuzz_value_sanitize

[moodmosaic]

/cc @BowTiedRadone

[fdefelici]

I’ve added a bunch of comments about the workflows.

I’d also like to raise a broader structural idea: instead of keeping the fuzz folder nested inside the clarity crate, would it make sense to move it under the contrib/ folder?

We could, for example, introduce a dedicated fuzzing/ folder inside contrib/, which could later house multiple fuzzers as we expand coverage. The current clarity/fuzz would simply become one of them:

contrib/  
    fuzzing/  
        clarity-fuzzer/   (current clarity/fuzz)  
        other1-fuzzer/  
        other2-fuzzer/  
        ...

This would avoid nested crates inside clarity, make the structure more consistent, and give us room to organize future fuzzers without cluttering core crates.

If we agree this structure is beneficial, we could address it in this PR. The effort should be minimal, and since we’re already restoring the old fuzzer, could be the right time to make this change.

[moodmosaic]

instead of keeping the fuzz folder nested inside the clarity crate, would it make sense to move it under the contrib/ folder?

Right now it makes more sense to keep the fuzz folder inside the clarity crate.

That way it matches how we handle example-based and property-based tests, and keeps fuzzing a first-class part of the folder/crate rather than something tucked away in contrib/.

Also, with this structure, cargo fuzz works naturally from the crate root without needing --manifest-path.

Moving it under contrib/ pays off when/if we had multiple independent fuzzers with shared arbitraries. Until then, local fuzz targets keep the workflow simple: "open the crate and see all its tests, including fuzz".

I think it’s a good idea to tackle reorganizing later, once we add more fuzzers, so we can keep #6355 moving.

[fdefelici]

LGTM!

Just adding a heads-up so we can make a common decision regarding cache management.

[kantai]

This looks good to me, I just had a question about re-using the generator implementations across the two targets.